From nobody Fri Jul 1 01:30:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9A12D187 for ; Fri, 1 Jul 2016 01:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 c1hobpm3l6hL for ; Fri, 1 Jul 2016 01:30:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5110C12D0D3 for ; Fri, 1 Jul 2016 01:30:49 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 47D5F1AE0398; Fri, 1 Jul 2016 10:30:48 +0200 (CEST) Date: Fri, 01 Jul 2016 10:31:13 +0200 (CEST) Message-Id: <20160701.103113.301947010745595267.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> 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: Cc: media-types@iana.org, netconf@ietf.org Subject: Re: [Netconf] request review of media type application/yang-data+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 08:30:51 -0000 Andy Bierman wrote: > removing all text except the fragment identifier issue.... > > According to RFC 7303, sec. 5, any usage of +xml requires implementation of > the XPointerFramework > https://www.w3.org/TR/2003/REC-xptr-framework-20030325/ Actually, it says SHOULD: If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, it SHOULD NOT follow the naming convention '+xml'. > RESTCONF "fragments" are sub-trees within the YANG data structures. > These are accessed by the request URI path and the "fields" query parameter. > XPointer is rather complex and completely redundant for RESTCONF. I'm not sure the "element()" scheme is complex to implement. The "fields" query parameter probably takes more effort to implement. Note though that the "fields" query parameter is more expressive than the "element()" scheme, and it works with other encodings than XML. *if* we were to use XPointer instead of "fields", what would we do for JSON? > So do we have to add text that a RESTCONF server MUST implement the > "element" > scheme? If this indeed is to be interpreted as a requirement, I'd rather not use the "+xml" name. /martin From nobody Fri Jul 1 02:07:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B511912D0C1 for ; Fri, 1 Jul 2016 02:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.927 X-Spam-Level: X-Spam-Status: No, score=-14.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdoGAl5RL52i for ; Fri, 1 Jul 2016 02:07:53 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3F012D0D3 for ; Fri, 1 Jul 2016 02:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2359; q=dns/txt; s=iport; t=1467364073; x=1468573673; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=XuKYh8qP0luzA983j6eSeyuVaQlTAwE28NdJswx3mBQ=; b=WQfWKwcZiWze9vxBYE+0EpF6NsRozPkUNSrre0ccSl4ox+SNn5EF2UN8 9BFL4rioUFR+bSYR3asBJlav1mrxCUF7OOlwypvCWYKc01Ku+3xnoIjdM 7EmdlTXrACzhp3rIVFHLTeAxSdSlzaX0pzqWGqmMprl3dbVgHiId3Wcwh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlBAC+MXZX/xbLJq1ahBQqRgy5UIF7I?= =?us-ascii?q?oV2AiiBRBQBAQEBAQEBZSeERAkBBQEBNhYrEAsUECInCiYTBgIBARAHAgSFUYI?= =?us-ascii?q?+DsQKAQEBAQEBAQECAQEBAQEBIYYogXeCVoE5gmgJgyeCSgEEmRCGCYg7gWqEV?= =?us-ascii?q?oMLhV+QCR42ghWBXToyAYc+gTUBAQU?= X-IronPort-AV: E=Sophos;i="5.26,556,1459814400"; d="scan'208";a="678023919" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2016 09:07:51 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6197oWs006023 for ; Fri, 1 Jul 2016 09:07:51 GMT References: <20160630174343.0C967B80B91@rfc-editor.org> Cc: netconf@ietf.org From: Benoit Claise Message-ID: <8e8c8f6f-bf7d-9c5e-0e29-19c55fda9feb@cisco.com> Date: Fri, 1 Jul 2016 11:07:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160630174343.0C967B80B91@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] RFC 7895 on YANG Module Library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 09:07:57 -0000 Congrats for this YANG model RFC. Regards, B. > A new Request for Comments is now available in online RFC libraries. > > > RFC 7895 > > Title: YANG Module Library > Author: A. Bierman, M. Bjorklund, > K. Watsen > Status: Standards Track > Stream: IETF > Date: June 2016 > Mailbox: andy@yumaworks.com, > mbj@tail-f.com, > kwatsen@juniper.net > Pages: 13 > Characters: 24164 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-yang-library-06.txt > > URL: https://www.rfc-editor.org/info/rfc7895 > > DOI: http://dx.doi.org/10.17487/RFC7895 > > This document describes a YANG library that provides information > about all the YANG modules used by a network management server (e.g., > a Network Configuration Protocol (NETCONF) server). Simple caching > mechanisms are provided to allow clients to minimize retrieval of > this information. > > This document is a product of the Network Configuration Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > . > From nobody Fri Jul 1 03:57:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB512D56C for ; Fri, 1 Jul 2016 03:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JVSc69tkk89z for ; Fri, 1 Jul 2016 03:57:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D029812D567 for ; Fri, 1 Jul 2016 03:57:32 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id F23EE1AE0398; Fri, 1 Jul 2016 12:57:31 +0200 (CEST) Date: Fri, 01 Jul 2016 12:57:57 +0200 (CEST) Message-Id: <20160701.125757.71813639576051509.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: 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: Cc: netconf@ietf.org Subject: Re: [Netconf] Some discussion points re: RFC 5277bis and YANG push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 10:57:35 -0000 Hi, I think this would be a useful feature. It would be harmless in most use cases, and useful in some specific use cases, e.g. generic proxies etc. /martin "Alexander Clemm (alex)" wrote: > Hi, > > draft-gonzalez-netconf-5277bis is another one of the drafts in the set > of drafts concerning event notifications and yang-push. > > One of the items wort bringing for discussion concerns the notion of > control plane notifications that are used to indicate the status of a > notification subscription. Examples of such notifications are > "replayComplete", "subscription-modified" (in case case of configured > subscriptions), and "subscription-suspended" (of particular importance > for draft-ietf-netconf-yang-push, another draft in the set, used by > the server to notify a client in case notification updates cannot be > sent as promised under various rainy-day scenarios). > > What makes those notifications different from other notifications is > that they are not of general concern, but of concern only for a > particular association. As a subscriber to event notifications, I > should only receive those notifications that concern "my" > subscription, not those that concern someone else's subscription. > > The way we are planning to address this is through introduction of an > extension "control-plane-notif". This extension is used to tag > definitions of notifications used for control / signaling purposes > that are therefore not part of the general NETCONF event stream. > Instead, notifications thus tagged are part of a signaling event > stream that is part of the signaling/control association implied by > the subscription. Like push-notifications themselves, there is a need > to distinguish notifications subscribable by everyone and notification > instances used by a server to notify items of significance to a > specific client, or set of clients. Please refer also to section 7 of > the draft > (https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-02#section-7 > ). > > We have been discussing this issue as part of the weekly calls in > which a subteam of NETCONF WG participants are discussing the set of > of related drafts and think this is one of the issues that we should > bring to the attention of and solicit feedback from the WG as a whole. > > Thoughts? > --- Alex > (on behalf of the team) > From nobody Fri Jul 1 08:42:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A3112B062 for ; Fri, 1 Jul 2016 08:42:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezJOjK9dD_ah for ; Fri, 1 Jul 2016 08:42:55 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0107.outbound.protection.outlook.com [104.47.41.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3053812D731 for ; Fri, 1 Jul 2016 08:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tfM2u1EJIIOvgoL/xZdaRZ2YjV8t3q94yfvgfLrQ5Dw=; b=IdEN5G0oaPlXrSqY4jwlAyu4O0Fy8BpjymHJ+bBhkSbriVMVpds9Nlvhjtt0dUhZSjBmIlSpx32uKvuu2NVtO7XngtTelebF+aUo4nqhkEgNtAuYVOriNWloRCo8fXLe6dS0bOSo5G98nIgq37bzUujAaYLMK08mM7N4JztM1XA= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 1 Jul 2016 15:42:52 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Fri, 1 Jul 2016 15:42:52 +0000 From: Kent Watsen To: Sean Turner Thread-Topic: netconf server-model (keychain) draft issues Thread-Index: AQHRq7oF1V9bdqG6E0qiTQDwkdd7LqAC3mqAgADlh4A= Date: Fri, 1 Jul 2016 15:42:52 +0000 Message-ID: <0DFCFDAF-6771-45AE-91BD-5DEE6829441F@juniper.net> References: <9040BCE7-A6A7-4134-9258-A27DB3BB0705@sn3rd.com> In-Reply-To: <9040BCE7-A6A7-4134-9258-A27DB3BB0705@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 0c755eb6-a419-4543-41d4-08d3a1c65d38 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 6:0ba08KKeV3A6rGneg4ORbUdtF9Zmw58iXS7IaeMjd3vw4qBVdY6ioDYBjGeKsHEkrRLFloTUXGsggtAnYfXidT6D81twT3p9G/LK6ir0d2rX+wjNFeui1NUko8+K61FDvLqPcUn6DSsSRzPierlx3UpCCRblFjEFRj1HilyMNxYHjzl5ScsAUiKEX/CRhcuYqwLUbeuTQYe+mFygnlTFiemoqjxib4lmPdt2aE/jdWhj4dRXG95NqCTyFVG19ssGAyFnnoKa4P0hSPYeEX6Kt6tSiPqVpBlaAedrLboT1gSsiEOAm3EWvKlMIgWOEtbr3OEhgI2yCm91KQ8A0ybVMQ==; 5:3jnXD6nQRJ8vWcYwJ+fUR31INA9zYQcHEEs71n6J3LZ9IfWXu8FdVRigQ3zM5pGUeOBxZKyh4daugOuqcwWgKX4nUYDK3pTt7GpLn9ljSRS18hTu0X1bxaYcWf4fRk9LLpC2ID87eJA4aKDc/HoxZg==; 24:4ZWS4E27uCmd6fJT0P29Rotz0W/4M6tWz0Dlz06hMnCsofTYVUiaUD9eNI1eo7B4GqCgzicWR8rv7MmWvLtMaAZf7Yu/tGKAEtOw5+rRxpg=; 7:gLyTPbONLGoJfh0fPhBfjiw6AVrzJ1FxST+Q/Fw8IHPm/LaMp9kNWdSorSVjVRzx5HbcORDdHAM9GE9DvpBGrGDu1QjhkjTupRnnBaCqQwMEQyDGgS8m3QKXfRbwVdcuGNCJ49nz8UIQL5toh0zoBBBuQ78R5PnwAN0+w9Dy3Gqee/ulRc45olpLNLc12rGSWm3pUaGeZ8o5EL67sszp972tjooh+7WpzBYMwkohygwsryu/OOPQypJGN2bkD2ky x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(76104003)(24454002)(377454003)(105586002)(97736004)(101416001)(77096005)(99286002)(82746002)(83716003)(83506001)(54356999)(189998001)(19580405001)(33656002)(50986999)(86362001)(4001350100001)(36756003)(106356001)(3280700002)(110136002)(19580395003)(586003)(106116001)(5002640100001)(76176999)(7846002)(102836003)(122556002)(2950100001)(11100500001)(4326007)(3660700001)(81156014)(6116002)(10400500002)(81166006)(305945005)(68736007)(7736002)(66066001)(92566002)(2900100001)(87936001)(3846002)(2906002)(15975445007)(345774005)(8676002)(8936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <82404E6F31235649A76C3B7A76D7775A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 15:42:52.6764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server-model (keychain) draft issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:42:57 -0000 DQpIaSBTZWFuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2UgLSBpdOKAmXMgbmV2ZXIg dG9vIGxhdGUhICAgOykNCg0KSSB0aGluayB5b3UgbWF5IGJlIG1peGluZyB1cCBjZXJ0cy1nZW5l cmF0aW9uIGFuZCBrZXktZ2VuZXJhdGlvbi4gICBJbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbC0wOSNzZWN0aW9uLTQuMS4xLCBrZXkt dXNhZ2UgaXMgYmVpbmcgdXNlZCBhcyBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSAnZ2VuZXJh dGUtcHJpdmF0ZS1rZXknIGNvbW1hbmQ6DQoNCiAgICAgICAgICstLS14IGdlbmVyYXRlLXByaXZh dGUta2V5DQogICAgICAgICAgICArLS0tdyBpbnB1dA0KICAgICAgICAgICAgICAgKy0tLXcgbmFt ZSAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgICstLS13IGtleS11c2FnZT8gICAgZW51 bWVyYXRpb24NCiAgICAgICAgICAgICAgICstLS13IGFsZ29yaXRobSAgICAga2M6YWxnb3JpdGht cw0KICAgICAgICAgICAgICAgKy0tLXcga2V5LWxlbmd0aD8gICB1aW50MzINCg0KVGhlIGlkZWEg YmVpbmcgdGhhdCBzeXN0ZW0gd2lsbCBzb21laG93IHJlbWVtYmVyIHdoeSB0aGUga2V5IHdhcyBj cmVhdGVkLiAgRm9yIGluc3RhbmNlLCB0aGlzIG1pZ2h0IGJlIGltcG9ydGFudCB3aGVuIGFza2lu ZyBhIFRQTSB0byBnZW5lcmF0ZSB0aGUga2V5Lg0KDQpTZXBhcmF0ZWx5LCB0aGUga2V5Y2hhaW4g bW9kZWwgaGFzIGEgY29uZmlndXJhdGlvbiBub2RlIHRvIGFzc29jaWF0ZSBjZXJ0aWZpY2F0ZXMg d2l0aCBhIHByaXZhdGUta2V5IGFuZCwgd2hlbiB0aGVzZSBjZXJ0cyBhcmUgZ2VuZXJhdGVkLCBJ IHdvdWxkIGV4cGVjdCB0aGF0IHRoZWlyIEtleVVzYWdlIHZhbHVlIHdvdWxkIGJlIHNldCBjb3Jy ZWN0bHkgZm9yIHRoZWlyIGFudGljaXBhdGVkIHVzZToNCg0KICAgICAgKy0tcncgcHJpdmF0ZS1r ZXlzDQogICAgICAgICAgKy0tcncgcHJpdmF0ZS1rZXkqIFtuYW1lXQ0KICAgICAgICAgICAgICst LXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCiAgICAg ICAgICAgICArLS1ybyBhbGdvcml0aG0/ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAga2M6 YWxnb3JpdGhtcw0KICAgICAgICAgICAgICstLXJvIGtleS1sZW5ndGg/ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1aW50MzINCiAgICAgICAgICAgICArLS1ybyBwdWJsaWMta2V5ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYmluYXJ5DQogICAgICAgICAgICAgKy0tcncgY2VydGlm aWNhdGUtY2hhaW5zDQogICAgICAgICAgICAgICAgKy0tcncgY2VydGlmaWNhdGUtY2hhaW4qIFtu YW1lXQ0KICAgICAgICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgIHN0cmluZw0KICAg ICAgICAgICAgICAgICAgICstLXJ3IGNlcnRpZmljYXRlKiAgIGJpbmFyeQ0KDQoNCkFzIEkgdW5k ZXJzdGFuZCBpdCwgdGhlIHByaXZhdGUga2V5IGl0c2VsZiBpcyB0eXBpY2FsbHkgKFRQTXMgd2l0 aHN0YW5kaW5nKSBjcmVhdGVkIHdpdGhvdXQgYXdhcmVuZXNzIG9mIGhvdyBpdCBtaWdodCBiZSB1 c2VkLiAgIEluIGdlbmVyYWwsIEnigJlkIHRoaW5rIHRoYXQgb3VyIOKAnGtleS11c2FnZeKAnSBp bnB1dCBwYXJhbWV0ZXIgd291bGQgbm90IGJlIHNldCwgdGVsbGluZyB0aGUgc3lzdGVtIHRvIGdl bmVyYXRlIGEgZ2VuZXJpYyBrZXkuICAgSWYgd2UgcmVtb3ZlIHN1cHBvcnQgZm9yIGdlbmVyYXRp bmcgcHJpdmF0ZSBrZXlzIHdpdGhpbiBhIFRQTSBmcm9tIHRoaXMgZHJhZnQsIEkgbWlnaHQgdGhp bmsgdG8gcmVtb3ZlIHRoZSDigJxrZXktdXNhZ2XigJ0gaW5wdXQgcGFyYW1ldGVyIGVudGlyZWx5 LiAgIA0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQpPbiA2 LzMwLzE2LCA2OjAxIFBNLCAiU2VhbiBUdXJuZXIiIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQoN ClNvcnJ5IGZvciBjb21wbGV0ZWx5IGRyb3BwaW5nIHRoZSBiYWxsIG9uIHRoaXMuICBIb3BlZnVs bHksIEkgY2FuIHJlZGVlbSBteXNlbGYgaGVyZS4NCg0KPiBPbiBNYXkgMTEsIDIwMTYsIGF0IDE1 OjE5LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiBIaSBT ZWFuLA0KPiANCj4gVGhhbmsgeW91IGFnYWluIGZvciB5b3VyIHJldmlldyBvZiB0aGUgc2VydmVy LW1vZGVsIGRyYWZ0IGJlZm9yZSwgcHJpbWFyaWx5IGZvY3VzaW5nIG9uIHRoZSBrZXljaGFpbiBt b2RlbC4gIEFzIHlvdSBrbm93LCBJIHVwZGF0ZWQgdGhlIGRyYWZ0IHNpZ25pZmljYW50bHkgYmFz ZWQgb24geW91ciBjb21tZW50cyBmb3IgOTUsIGJ1dCBvbmUgaXNzdWUgcmVtYWlucy4uLiANCj4g DQo+IFRoZSByZW1haW5pbmcgaXNzdWUgcmVnYXJkcyAna2V5LXVzYWdlJyBpbiB0aGUgZ2VuZXJh dGUtcHJpdmF0ZS1rZXkgYWN0aW9uIGxpc3RlZCBvbiBwYWdlIDIzIG9mIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtc2VydmVyLW1vZGVsLTA5LiAgQmVsb3cg aXMgdGhlIGN1cnJlbnQgKGluY29tcGxldGUpIGRlZmluaXRpb246DQo+IA0KPiAgICAgICAgICAg bGVhZiBrZXktdXNhZ2Ugew0KPiAgICAgICAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gICAg ICAgICAgICAgICBlbnVtIHNpZ25pbmcgICAgeyBkZXNjcmlwdGlvbiAic2lnbmluZyI7IH0NCj4g ICAgICAgICAgICAgICBlbnVtIGVuY3J5cHRpb24geyBkZXNjcmlwdGlvbiAiZW5jcnlwdGlvbiI7 IH0NCj4gICAgICAgICAgICAgICAvLyB1bmNsZWFyIGlmIHRoZXNlIHNob3VsZCBiZSBzb21laG93 IG1vcmUNCj4gICAgICAgICAgICAgICAvLyBzcGVjaWZpYyBvciB2YXJpZWQuDQo+ICAgICAgICAg ICAgIH0NCj4gDQo+IFRoZSBxdWVzdGlvbiBpcyBob3cgdG8gbWFrZSB0aGlzIGtleS11c2FnZSBk ZWZpbml0aW9uIGNvbXBsZXRlPyAgSSBjYW4gZG8gdGhlIFlBTkcgdHJhbnNsYXRpb24sIGJ1dCB3 aGF0IGFyZSB0aGUgcG9zc2libGUgdmFsdWVzPyAgSXMgaXQgdGhlIGNhc2UgdGhhdCB0aGUgaXNz dWUgb25seSBtYXR0ZXJzIHdoZW4gZGlzY3Vzc2luZyBUUE1zLCB3aGljaCBoYXZlIHZlcnkgZGlz dGluY3QgYW5kIHNwZWNpZmljIHVzYWdlIHByb2ZpbGVzPyAgIEFzIGEgZ2VuZXJpYyBrZXljaGFp biBtb2RlbCwgaXQgc2hvdWxkbid0IGJlIHNwZWNpZmljIHRvIG5ldHdvcmsgbWFuYWdlbWVudCwg YnV0IGl0IHdvdWxkIGJlIHJlbWlzcyBmb3IgbWUgdG8gbm90IHBvaW50IG91dCB0aGF0LCBpbiBu ZXR3b3JrIG1hbmFnZW1lbnQsIHRoZSBwcml2YXRlIGtleSBzZWVtcyB0byBhbHdheXMgaGF2ZSB0 aGUgc2FtZSBrZXkgdXNhZ2UgKGkuZS4gd2hhdCdzIG5lZWRlZCB0byBlc3RhYmxpc2ggYSBTU0gv VExTIHR1bm5lbCkuICAgVGhvdWdodHM/DQo+IA0KPiBUaGFua3MsDQo+IEtlbnQNCg0KQXMgZmFy IGFzIGNvbXBsZXRlbmVzcyBnb2VzLCBpdOKAmXMgZ29pbmcgdG8gYmUgaGFyZCBiZWNhdXNlIG9u ZSBvZiB0aGUgZmllbGRzIGRlZmluZWQgdG8gY2Fycnkga2V5IHVzYWdlIGluIHRoZSBjZXJ0aWZp Y2F0ZSBpcyBvcGVuIGVuZGVkLiAgQXMgZmFyIGFzIGJhY2tncm91bmQgZ29lcyB0aGVyZeKAmXMg dHdvIGtleSB1c2FnZSBmaWVsZHMgaW4gYSBjZXJ0IGFuZCB0aGV5IGJvdGggaW4gZXh0ZW5zaW9u czoNCg0KMC4gS2V5IFVzYWdlIGNhbiBiZSBmb3VuZCBpbiBzNC4yLjEuMyBvZiBSRkMgNTI4MC4g IEl0IGxpc3RzIHNvbWUgdXNhZ2VzIHRoYXQgdGhlIElUVS9JRVRGIGZvbGtzIHRob3VnaHQgd2Vy ZSB1c2VmdWwgKGFwb2xvZ2llcyBmb3IgdGhlIEFTTi4xKToNCg0KS2V5VXNhZ2UgOjo9IEJJVCBT VFJJTkcgew0KICBkaWdpdGFsU2lnbmF0dXJlICAoMCksDQogIG5vblJlcHVkaWF0aW9uICAoMSks IC0tIHJlY2VudCBlZGl0aW9ucyBvZiBYLjUwOSBoYXZlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIHJlbmFtZWQgdGhpcyBiaXQgdG8gY29udGVudENvbW1pdG1lbnQNCiAga2V5 RW5jaXBoZXJtZW50ICAgICAgICAgKDIpLA0KICBkYXRhRW5jaXBoZXJtZW50ICAgICAgICAoMyks DQogIGtleUFncmVlbWVudCAgICAgICAgICAgICg0KSwNCiAga2V5Q2VydFNpZ24gICAgICAgICAg ICAgKDUpLA0KICBjUkxTaWduICAgICAgICAgICAgICAgICAoNiksDQogIGVuY2lwaGVyT25seSAg ICAgICAgICAgICg3KSwNCiAgZGVjaXBoZXJPbmx5ICAgICAgICAgICAgKDgpIH0NCg0KMS4gQW5k IGJlY2F1c2UgdGhhdCBsaXN0IGlzbuKAmXQgYWxsIGVuY29tcGFzc2luZyB0aGV5IGFsc28gZGVm aW5lZCBhbiBFeHRlbmRlZCBLZXkgVXNhZ2VzIGV4dGVuc2lvbiB3aGljaCBpcyBlc3NlbnRpYWxs eSBhIHNlcXVlbmNlIG9mIE9JRHMuICBBIGJ1bmNoIGhhdmUgYmVlbiBkZWZpbmVkIGhlcmU6DQpo dHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zbWktbnVtYmVycy9zbWktbnVtYmVycy54 aHRtbCNzbWktbnVtYmVycy0xLjMuNi4xLjUuNS43LjMNCkJlY2F1c2UgYW55Ym9keSBjYW4gZ2V0 IGFuIE9JRCwgYW55Ym9keSBjYW4gZGVmaW5lIGEga2V5IHVzYWdlIHNvIHRoYXQgbGlzdCBpc27i gJl0IGFsbCBlbmNvbXBhc3NpbmcuDQoNCkFzIGZhciBhcyB3aGF0IHBlb3BsZSB1c2UsIG1vc3Qg VExTIGNlcnRpZmljYXRlcyBpbmNsdWRlIGJvdGggaWQta3Atc2VydmVyQXV0aCBhbmQgaWQta3At Y2xpZW50QXV0aC4gIEnigJlsbCBuZWVkIHRvIGdvIGRpZyB1cCB3aGF0IHNzaC1iYXNlZCBjZXJ0 aWZpY2F0ZXMgdXNlLiAgRG9lcyB0aGlzIGF0IGxlYXN0IGFuc3dlciBzb21lIG9mIGl0Pw0KDQpz cHQNCg0KDQoNCg0KDQo= From nobody Fri Jul 1 10:17:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66B112D501 for ; Fri, 1 Jul 2016 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_gM449Pk491 for ; Fri, 1 Jul 2016 10:17:52 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEE912D1DD for ; Fri, 1 Jul 2016 10:17:52 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id t127so212882338qkf.1 for ; Fri, 01 Jul 2016 10:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CGSCRKCkRh1sPWx/r/F+QPOxzd1V1kuIXwIptgZtuno=; b=asJzd2ARRCgKyqqXzfZe2ywz8n4o2qGMSP9dN85u42tC+KY0+mw953KIOfLlUEKTKQ tlILkQU7fsPjK0iaZvn79z44rojmL8/p8lN4A5tQeHu9uCY4RhlXWqD4d3+vd2jb2mSW Yta13mCSjEs9giCwzKehrCY+amiowb0X4Hs3A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CGSCRKCkRh1sPWx/r/F+QPOxzd1V1kuIXwIptgZtuno=; b=nLcGj6YFcvsiE+r8HZ9lzVjiNRXOScxDPUhGuquXWEfZUeoZGw+YYc0icSE+mFRlzs HnXfRp8mWClD8DITNo+wWdIcu8hRfVRDhcXpX1cBvRwJZq5QUnj//kcm40CyzCJZ+LU0 cDnNfwe5CtyBxE9i6xx98p+4XMsyoXdCIARzTkTdAu3yxOqPEiOc76TGWioJqBni+HU2 4cgnqtgVPZfxwg7zOqmx6wPOzFoMpaXP70eUVXaNr33GfDKtvcv45ZwWc9vOZEvLZcnD V9FtdAhYHgVnU8AVPxXz7qiX5No24VyvLMsfigBsm+PoybuyoeYs2JRJ5TrUxmcMabgH W04w== X-Gm-Message-State: ALyK8tJLNcGp1XE1AUhtfAJjrsq6i52zaHeh0Wt30HRAusonkkGcPDeJGEgYNBRhm2YuKA== X-Received: by 10.55.88.65 with SMTP id m62mr30058823qkb.0.1467393471408; Fri, 01 Jul 2016 10:17:51 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id j131sm2390516qke.22.2016.07.01.10.17.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Jul 2016 10:17:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <0DFCFDAF-6771-45AE-91BD-5DEE6829441F@juniper.net> Date: Fri, 1 Jul 2016 13:17:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9040BCE7-A6A7-4134-9258-A27DB3BB0705@sn3rd.com> <0DFCFDAF-6771-45AE-91BD-5DEE6829441F@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server-model (keychain) draft issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 17:17:55 -0000 Ah yep you=E2=80=99re right I=E2=80=99m conflating cert-gen and key-gen. = When you do a key-gen in say openssl you=E2=80=99re say give me key = pair with these parameters (algorithm, key size, curve, etc.). You = might give it more parameters for one of the =E2=80=9Ccombo=E2=80=9D = commands (e.g., generate self-signed certificate), but then you=E2=80=99re= just combining multiple steps sequentially and the key-gen step is = still just make key pair with these parameters. Also, because private keys aren=E2=80=99t normally exchanged there=E2=80=99= s not a lot of standardization wrt to ways to indicate private key = usages/purpose. There are some, but I categorize them as exotic. Finally, if you=E2=80=99ve organized the private and public keys so that = they=E2=80=99re related (maybe both are subordinate to the same parent = node/object) then you=E2=80=99ll get the key usages from the public key. = This is kind of like when you store the private and public key in a = PKCS#8, both keys are together and you can figure out what the private = key should be used for based on the public key algorithm, key usages, = etc. Hope this helps. spt > On Jul 01, 2016, at 11:42, Kent Watsen wrote: >=20 >=20 > Hi Sean, >=20 > Thank you for your response - it=E2=80=99s never too late! ;) >=20 > I think you may be mixing up certs-generation and key-generation. In = https://tools.ietf.org/html/draft-ietf-netconf-server-model-09#section-4.1= .1, key-usage is being used as an input parameter for the = 'generate-private-key' command: >=20 > +---x generate-private-key > +---w input > +---w name string > +---w key-usage? enumeration > +---w algorithm kc:algorithms > +---w key-length? uint32 >=20 > The idea being that system will somehow remember why the key was = created. For instance, this might be important when asking a TPM to = generate the key. >=20 > Separately, the keychain model has a configuration node to associate = certificates with a private-key and, when these certs are generated, I = would expect that their KeyUsage value would be set correctly for their = anticipated use: >=20 > +--rw private-keys > +--rw private-key* [name] > +--rw name string > +--ro algorithm? = kc:algorithms > +--ro key-length? uint32 > +--ro public-key binary > +--rw certificate-chains > +--rw certificate-chain* [name] > +--rw name string > +--rw certificate* binary >=20 >=20 > As I understand it, the private key itself is typically (TPMs = withstanding) created without awareness of how it might be used. In = general, I=E2=80=99d think that our =E2=80=9Ckey-usage=E2=80=9D input = parameter would not be set, telling the system to generate a generic = key. If we remove support for generating private keys within a TPM = from this draft, I might think to remove the =E2=80=9Ckey-usage=E2=80=9D = input parameter entirely. =20 >=20 > What do you think? >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 > On 6/30/16, 6:01 PM, "Sean Turner" wrote: >=20 > Sorry for completely dropping the ball on this. Hopefully, I can = redeem myself here. >=20 >> On May 11, 2016, at 15:19, Kent Watsen wrote: >>=20 >> Hi Sean, >>=20 >> Thank you again for your review of the server-model draft before, = primarily focusing on the keychain model. As you know, I updated the = draft significantly based on your comments for 95, but one issue = remains...=20 >>=20 >> The remaining issue regards 'key-usage' in the generate-private-key = action listed on page 23 of = https://tools.ietf.org/html/draft-ietf-netconf-server-model-09. Below = is the current (incomplete) definition: >>=20 >> leaf key-usage { >> type enumeration { >> enum signing { description "signing"; } >> enum encryption { description "encryption"; } >> // unclear if these should be somehow more >> // specific or varied. >> } >>=20 >> The question is how to make this key-usage definition complete? I = can do the YANG translation, but what are the possible values? Is it = the case that the issue only matters when discussing TPMs, which have = very distinct and specific usage profiles? As a generic keychain = model, it shouldn't be specific to network management, but it would be = remiss for me to not point out that, in network management, the private = key seems to always have the same key usage (i.e. what's needed to = establish a SSH/TLS tunnel). Thoughts? >>=20 >> Thanks, >> Kent >=20 > As far as completeness goes, it=E2=80=99s going to be hard because one = of the fields defined to carry key usage in the certificate is open = ended. As far as background goes there=E2=80=99s two key usage fields = in a cert and they both in extensions: >=20 > 0. Key Usage can be found in s4.2.1.3 of RFC 5280. It lists some = usages that the ITU/IETF folks thought were useful (apologies for the = ASN.1): >=20 > KeyUsage ::=3D BIT STRING { > digitalSignature (0), > nonRepudiation (1), -- recent editions of X.509 have > -- renamed this bit to = contentCommitment > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } >=20 > 1. And because that list isn=E2=80=99t all encompassing they also = defined an Extended Key Usages extension which is essentially a sequence = of OIDs. A bunch have been defined here: > = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.3 > Because anybody can get an OID, anybody can define a key usage so that = list isn=E2=80=99t all encompassing. >=20 > As far as what people use, most TLS certificates include both = id-kp-serverAuth and id-kp-clientAuth. I=E2=80=99ll need to go dig up = what ssh-based certificates use. Does this at least answer some of it? >=20 > spt >=20 >=20 >=20 >=20 >=20 From nobody Fri Jul 1 10:44:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF14512D796 for ; Fri, 1 Jul 2016 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyhihZ4l8qjj for ; Fri, 1 Jul 2016 10:44:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4809212D791 for ; Fri, 1 Jul 2016 10:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11372; q=dns/txt; s=iport; t=1467395054; x=1468604654; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LiFT1DXn4VNT2h/RpqMSGzMFADzA5aTX2Y0/+ql3AUg=; b=i/taLvlWBZTJxYe2GyPzB2Z/gqaWVbQQIf+z15HB2YBPmSzb0Kp+rlLj imcji63vKMMgxVSLidQmtmCmJ/hgwY3o5Ju1EBG5KvtqklEwtIApYKqEc qGfOB9OqDM4snv55MSNGfXQpzi8PeWnghk/SN8uRbo3cuvoeuIQCTkYVL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgACq3ZX/5pdJa1dgnBOVnwGtEuFA?= =?us-ascii?q?YF7IoUsSgIcgRU4FAEBAQEBAQFlJ4RNAQUjCkELEAIBCD8DAgICMBQRAgQBDQU?= =?us-ascii?q?IiCgOtEuQCQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiiETYQjAQEFJAmCaoJaB?= =?us-ascii?q?ZNWhToBiQKFPI8xkAgBHjaDcG4Bhz42fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,558,1459814400"; d="scan'208,217";a="121396965" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2016 17:44:13 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u61HiC2q008155 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 17:44:13 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 1 Jul 2016 13:44:11 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 1 Jul 2016 13:44:11 -0400 From: "Eric Voit (evoit)" To: Andy Bierman , "Benoit Claise (bclaise)" Thread-Topic: [Netconf] AD review of draft-ietf-netconf-restconf-13 Thread-Index: AQHR0079Bb97qyvcr0SoS3VG6WaIn6ADz+rA Date: Fri, 1 Jul 2016 17:44:11 +0000 Message-ID: <7a091e787f6a42ac9bb7d5225f042988@XCH-RTP-013.cisco.com> References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.231] Content-Type: multipart/alternative; boundary="_000_7a091e787f6a42ac9bb7d5225f042988XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETCONF Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 17:44:17 -0000 --_000_7a091e787f6a42ac9bb7d5225f042988XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSBCaWVybWFuLCBKdWx5IDAxLCAyMDE2IDEyOjEzIEFNDQpPbiBXZWQsIEp1biAyOSwgMjAx NiBhdCA2OjEzIEFNLCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNs YWlzZUBjaXNjby5jb20+PiB3cm90ZToNCg0KDQotIHNlY3Rpb24gMQ0KDQpSRVNUQ09ORiBpcyBi YXNlZCBvbiBIVFRQMS4xIFtSRkM3MjMwXQ0KDQpXaGF0IGFib3V0IEhUVFAyIFtSRkM3NTQwXT8N Cg0KSSd2ZSBzZWVuIHNvbWUgZGlzY3Vzc2lvbnMgb24gdGhlIE5FVENPTkYgbWFpbGluZyBidXQg SSdtIHVuY2xlYXIgaWYgUkVTVENPTkYgd291bGQgd29yayB3aXRoIEhUVFAyLg0KDQpBIGZldyB3 b3JkcyBhcmUgbmVjZXNzYXJ5IElNTy4NCg0KYmFja2dyb3VuZDogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDg1NzguaHRtbA0KDQpJIHNl ZSBpbiBzZWN0aW9uIDIuMQ0KDQogICBObyBvdGhlciB2ZXJzaW9ucyBvZiBIVFRQIGFyZSBzdXBw b3J0ZWQgZm9yIHVzZSB3aXRoIFJFU1RDT05GLg0KDQpEbyB5b3UgbWVhbjoNCg0KICAgTm8gb3Ro ZXIgdmVyc2lvbnMgdGhhbiBIVFRQIDEuMSBhcmUgc3VwcG9ydGVkIGZvciB1c2Ugd2l0aCBSRVNU Q09ORi4NCg0KU286DQoNCiAgIEhUVFAyLjAgTVVTVCBOT1QgYmUgdXNlZCB3aXRoIFJFU1RDT05G Lg0KDQpJZiB0aGlzIGlzIHRoZSBjYXNlLCBzb21lIHNvcnQgb2YganVzdGlmaWNhdGlvbiBpcyBy ZXF1aXJlZC4NCg0KDQpZb3UgaGF2ZSB0byBzYXkgc29tZXRoaW5nIGFib3V0IEhUVFAyDQoNCg0K VGhlIFdHIG5lZWRzIHRvIGRlY2lkZSB3aGF0IHRvIHNheSwgYW5kIHdoYXQgc2VjdGlvbiBuZWVk cyB0byBiZSB1cGRhdGVkLg0KVGhlcmUgaXMgYSBsb3Qgb2YgdGV4dCB0aGF0IGNpdGVzIEhUVFAg MS4xLg0KDQpJIHdvdWxkIHByZWZlciBhIHNtYWxsIG51bWJlciBvZiBlZGl0czsgTVVTVCBzdXBw b3J0IEhUVFAgMS4xOyBNQVkgc3VwcG9ydCBIVFRQLzINCg0KDQo8RXJpYz4gIEhUVFAvMiBuZWVk cyB0byBiZSBhbGxvd2VkLCBldmVuIGlmIG5vIHRleHQgZXhhbXBsZXMgYXJlIHByb3ZpZGVkLg0K DQpJcyB0aGVyZSBhbnkgY29uY2VybiB3aXRoIHNlcXVlbmNpbmcgb2YgdHJhbnNhY3Rpb25zIGhl cmU/ICBTZWN0aW9uIDIuMSBzYXlzIOKAnFJlc3BvbnNlcyBNVVNUIGJlIHNlbnQgaW4gdGhlIHNh bWUgb3JkZXIgdGhhdCByZXF1ZXN0cyBhcmUgcmVjZWl2ZWQu4oCdICAgRGlmZmVyZW50IFBPU1Qs IFBVVCwgUEFUQ0ggU2VydmVyIHJlc3BvbnNlcyBtaWdodCBlbmQgdXAgb24gZGlmZmVyZW50IEhU VFAvMiBzdHJlYW1zIGFuZCBzdGlsbCBtZWV0IHRoaXMgcmVxdWlyZW1lbnQuICBXZSBzaG91bGQg cHJlY2x1ZGUgdGhpcyBwb3NzaWJpbGl0eSBpbiB0aGUgdGV4dC4NCg0KSXMgaXQgZmVhc2libGUg dG8gYWRkIHJlcXVpcmVtZW50IHRoYXQgYWxsIHJlcXVlc3RzIG1hZGUgZnJvbSBvbmUgSFRUUC8y IHN0cmVhbSBtdXN0IGJlIHJldHVybmVkIHdpdGhpbiBhIHNpbmdsZSBIVFRQLzIgc3RyZWFtPyAg IFRoaXMgd291bGQgZW5hYmxlIHBpcGVsaW5pbmcgZm9yIGFuIGluaXRpYXRpbmcgYXBwbGljYXRp b24uICAgSXQgd291bGQgYWxzbyBhbGxvdyBwYXJhbGxlbGlzbSBmb3IgUkVTVENPTkYgU2VydmVy IGluaXRpYXRlZCBtZXNzYWdlcyB3aGljaCBjYW4gc2FmZWx5IGJlIG11bHRpcGxleGVkLg0KDQpF cmljDQo= --_000_7a091e787f6a42ac9bb7d5225f042988XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbmR5IEJpZXJtYW4sIEp1bHkgMDEsIDIwMTYg MTI6MTMgQU08YnI+DQo8L3NwYW4+T24gV2VkLCBKdW4gMjksIDIwMTYgYXQgNjoxMyBBTSwgQmVu b2l0IENsYWlzZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+YmNsYWlzZUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHByZT4tIHNlY3Rpb24gMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJFU1RDT05GIGlzIGJh c2VkIG9uIEhUVFAxLjEgW1JGQzcyMzBdPG86cD48L286cD48L3ByZT4NCjxwcmU+V2hhdCBhYm91 dCBIVFRQMiBbUkZDNzU0MF0/IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkndmUgc2VlbiBzb21l IGRpc2N1c3Npb25zIG9uIHRoZSBORVRDT05GIG1haWxpbmcgYnV0IEknbSB1bmNsZWFyIGlmIFJF U1RDT05GIHdvdWxkIHdvcmsgd2l0aCBIVFRQMi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BIGZl dyB3b3JkcyBhcmUgbmVjZXNzYXJ5IElNTy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iYWNrZ3Jv dW5kOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNv bmYvY3VycmVudC9tc2cwODU3OC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDg1NzguaHRtbDwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIHNlZSBpbiBzZWN0aW9uIDIuMTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBObyBvdGhlciB2ZXJzaW9ucyBvZiBIVFRQIGFyZSBzdXBw b3J0ZWQgZm9yIHVzZSB3aXRoIFJFU1RDT05GLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRvIHlv dSBtZWFuOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBObyBvdGhlciB2ZXJz aW9ucyB0aGFuIEhUVFAgMS4xIGFyZSBzdXBwb3J0ZWQgZm9yIHVzZSB3aXRoIFJFU1RDT05GLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBIVFRQMi4wIE1VU1QgTk9UIGJlIHVzZWQgd2l0aCBSRVNUQ09ORi48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5JZiB0aGlzIGlzIHRoZSBjYXNlLCBzb21lIHNvcnQgb2YganVzdGlmaWNhdGlv biBpcyByZXF1aXJlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBoYXZlIHRvIHNheSBzb21ldGhpbmcgYWJvdXQg SFRUUDI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgV0cgbmVlZHMgdG8gZGVjaWRlIHdoYXQgdG8gc2F5LCBh bmQgd2hhdCBzZWN0aW9uIG5lZWRzIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhIGxvdCBvZiB0ZXh0IHRo YXQgY2l0ZXMgSFRUUCAxLjEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcHJlZmVyIGEgc21hbGwgbnVtYmVyIG9mIGVkaXRzOyBN VVNUIHN1cHBvcnQgSFRUUCAxLjE7IE1BWSBzdXBwb3J0IEhUVFAvMjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtFcmljJmd0 OyZuYnNwOyBIVFRQLzIgbmVlZHMgdG8gYmUgYWxsb3dlZCwgZXZlbiBpZiBubyB0ZXh0IGV4YW1w bGVzIGFyZSBwcm92aWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRoZXJlIGFueSBjb25jZXJuIHdpdGggc2Vx dWVuY2luZyBvZiB0cmFuc2FjdGlvbnMgaGVyZT8mbmJzcDsgU2VjdGlvbiAyLjEgc2F5cyDigJxS ZXNwb25zZXMgTVVTVCBiZSBzZW50IGluIHRoZSBzYW1lIG9yZGVyIHRoYXQgcmVxdWVzdHMgYXJl IHJlY2VpdmVkLuKAnSZuYnNwOyAmbmJzcDtEaWZmZXJlbnQNCiBQT1NULCBQVVQsIFBBVENIIFNl cnZlciByZXNwb25zZXMgbWlnaHQgZW5kIHVwIG9uIGRpZmZlcmVudCBIVFRQLzIgc3RyZWFtcyBh bmQgc3RpbGwgbWVldCB0aGlzIHJlcXVpcmVtZW50LiZuYnNwOyBXZSBzaG91bGQgcHJlY2x1ZGUg dGhpcyBwb3NzaWJpbGl0eSBpbiB0aGUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIGl0IGZlYXNpYmxlIHRv IGFkZCByZXF1aXJlbWVudCB0aGF0IGFsbCByZXF1ZXN0cyBtYWRlIGZyb20gb25lIEhUVFAvMiBz dHJlYW0gbXVzdCBiZSByZXR1cm5lZCB3aXRoaW4gYSBzaW5nbGUgSFRUUC8yIHN0cmVhbT8mbmJz cDsgJm5ic3A7VGhpcyB3b3VsZCBlbmFibGUgcGlwZWxpbmluZw0KIGZvciBhbiBpbml0aWF0aW5n IGFwcGxpY2F0aW9uLiZuYnNwOyZuYnNwOyBJdCB3b3VsZCBhbHNvIGFsbG93IHBhcmFsbGVsaXNt IGZvciBSRVNUQ09ORiBTZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIHdoaWNoIGNhbiBzYWZlbHkg YmUgbXVsdGlwbGV4ZWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7a091e787f6a42ac9bb7d5225f042988XCHRTP013ciscocom_-- From nobody Fri Jul 1 18:21:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281D12D09D for ; Fri, 1 Jul 2016 18:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9JfqF9IGn7o for ; Fri, 1 Jul 2016 18:21:26 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE16F12B043 for ; Fri, 1 Jul 2016 18:21:25 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id c2so173542338vkg.1 for ; Fri, 01 Jul 2016 18:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8In2zuYVAWMbOyBGVB5lnaJS1Z3zI7kLNBIy0JEwKno=; b=zivP9viYufvBk5Qjepg1Z+QchSo1WURSMx/zBJXL70r1lYThv2ma5diLYuh2O/hIYx RnLJAzw4iEEpwfD91d6MnVT572B2LV1YtcoulkJPaW6LA3SDcG3q2t6lkC8unbI6loNb +Vj/J4bGKi2Nq9a8J6drT18MOeYNSigMXTnd+6LXfwc0ACjCgBcn3V4tmbOMNpc3+/Z9 23Bgz94dF/m3L4kLQamRvziLT0paTrCtdpn0KuUNtpsdoIZR/4nE3RuZR2WBhuO9lefw WklhvNHNCqAfLOGIsCsLjGWxSxKqUGw043oON9pHWIdZONfJKSoEvSwHwRD9UP4PFaFo Fzew== 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; bh=8In2zuYVAWMbOyBGVB5lnaJS1Z3zI7kLNBIy0JEwKno=; b=YQ9ltV9FshG3KiVedeW6jGKZxenVmnigWp6L3nssXgQurChJ7VFJfeFDqmiRVk+mPh RrblcAIKnExxa0tfTo5vetBfT76fK/Pc0Mged7veWv00MM2sOJDgFHdeFnkWFhp0HmKc YsDlR/4vYMQKczMrT6c0RntW9zMxJIvZVAbiduFsIkfE/e+NoT8cdUsgctOuqRvzii/z kg52wSlGVjGJDWS5TNwGEChklAohm/MQyVplwW5KAEufr14qUNmay2WUL50J/buxTdGg nYnR/dnG4kudo+wHBRy7rYqvITd/CLbOqfTGlOLF8DJ3JDBRmWqGjwSTaXmJhHRT5x9G W08w== X-Gm-Message-State: ALyK8tL6sUC2esZ0ej7gywSjtZ9DzpWp/GwYUZOjJBgMtGh9Ic3zyMwCEOj2AQTlt7qjp4GtJTwZemY56Cg1Dg== X-Received: by 10.31.174.214 with SMTP id x205mr624436vke.13.1467422484902; Fri, 01 Jul 2016 18:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 1 Jul 2016 18:21:24 -0700 (PDT) From: Andy Bierman Date: Fri, 1 Jul 2016 18:21:24 -0700 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary=001a11438728f2c71f05369cebf3 Archived-At: Subject: [Netconf] few comments on yang-push-03, notifs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 01:21:27 -0000 --001a11438728f2c71f05369cebf3 Content-Type: text/plain; charset=UTF-8 Hi, I think the YANG Push draft is useful work. We can debate every little feature I guess (because there are a lot of them). But not enough YANG features. XPath filtering is mandatory to implement here, but it is optional in NETCONF. I agree that "on-change" should be an optional feature and periodic should be mandatory. IMO modify-subscription (in rfc5277-bis) should be optional. I consider the overlap between 'no-success' and to be a big open issue. IMO, special 1-off error handling is a bad precedent. Both NETCONF and RESTCONF say to send an error response if the operation does not succeed. Andy --001a11438728f2c71f05369cebf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think the YANG Push draft is usef= ul work.
We can debate every little feature I guess (because ther= e are a lot of them).

But not enough YANG features= .
XPath filtering is mandatory to implement here, but it is optio= nal in NETCONF.

I agree that "on-change"= should be an optional feature and periodic
should be mandatory.<= /div>

IMO modify-subscription (in rfc5277-bis) should be= optional.

I consider the overlap between 'no-= success' and <rpc-error> to be a big open issue.
IMO, s= pecial 1-off error handling is a bad precedent.
Both NETCONF and = RESTCONF say to send an error response
if the operation does not = succeed.


Andy

<= div>


--001a11438728f2c71f05369cebf3-- From nobody Sat Jul 2 01:31:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9220E12D0F7 for ; Sat, 2 Jul 2016 01:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv7IBG75-4CB for ; Sat, 2 Jul 2016 01:31:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2191612B02A for ; Sat, 2 Jul 2016 01:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47175; q=dns/txt; s=iport; t=1467448313; x=1468657913; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+2MjoPENOf+irwjzqQVpAp3L8KVC+IO8viwEqSCpOe0=; b=ZXkzZLnLF40cc2KeKzFahxJeC0Vb3+3CgC+rDEA1nQkZ/0q1XVoAqNlh u0nm3ih4/hQaeoAXTpDFWVeNiHu4ZGbeLRjj39+dA+0V0Azw5lL2TICrh BC870GCJ6V3zSwLiS6LosyB85ToQF2I5/nGuxpQW4wclLcxnZYKCoXolA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9BAA2e3dX/xbLJq1chBQqUrsuIoUsS?= =?us-ascii?q?gKBdgEBAQEBAWYnhEwBAQQBGglEBwsQCQIYIAEGAwICRhEGDQYCAQGIJAgOlUq?= =?us-ascii?q?dHZABAQEBAQEBAQMBAQEBAQEBAQEBARyGKIF4CIJNhCMBAQWDF4JaAQSOAoVVh?= =?us-ascii?q?TqGCYg/gWpOhAiDC4VfhleJM1SCCByBTjoyAYdpDRcHgRcBAQE?= X-IronPort-AV: E=Sophos;i="5.26,562,1459814400"; d="scan'208,217";a="636507621" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2016 08:31:50 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u628VnFT022422; Sat, 2 Jul 2016 08:31:50 GMT To: Andy Bierman References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> From: Benoit Claise Message-ID: Date: Sat, 2 Jul 2016 10:31:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030B8D595DE2286131B6DBBF" Archived-At: Cc: NETCONF Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 08:31:57 -0000 This is a multi-part message in MIME format. --------------030B8D595DE2286131B6DBBF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, > > > On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise > wrote: > > Dear authors, > > Thanks for this new draft. I removed the points that are integrated. > Note: I wished that the authors had replied with the points (not) > addressed, instead of me spending a couple of hours reviewing all > comments and diffs. > > First of, there is an issue with the YANG module extraction > > xym.py draft-ietf-netconf-restconf-14.txt > ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - > 'module' statement within another module > Created the following models:: > example-ops.yang > example-actions.yang > example-jukebox.yang > example-mod.yang > > > I did not get any YANG errors in idnits. Investigating with Henrik. > It is true that we validate the example modules without the --ietf option. > IMO, this MUST only be for modules enclosed in > I don't complain about the examples. The issue is https://github.com/xym-tool/xym/issues/5 > We never resolved the issue of > There was no consensus that it was needed or how to do it. > So let's decide now. > > > > > > Not an issue with the draft, but with the xym.py that can't deal > with a module example in a description: > > container operations { > description > "Container for all operation resources > (application/yang-operation), > > Each resource is represented as an empty leaf with the > name of the RPC operation from the YANG rpc statement. > For example, the 'system-restart' RPC operation defined > in the 'ietf-system' module would be represented as > an empty leaf in the 'ietf-system' namespace. This is > a conceptual leaf, and will not actually be found in > the module: > > module ietf-system { <===== > leaf system-reset { > type empty; > } > } > > Bug filed for xym.py > Testing https://github.com/donaldh/yang-extractor (which I learned > of today), it works fine on this draft. > Currently testing the other drafts. > > See in-line. >> Dear all, >> >> Here is my draft-ietf-netconf-restconf-13 AD review >> [sorry for the delay, it took longer than expected]. >> If some of the points have already been discussed, let me know. >> >> -https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue >> There are still open issues. I would have expected that all issues are closed. Should I be worried? >> - From the charter: >> The RESTCONF work will consider requirements suggested by the other working groups >> (for example I2RS). >> >> Are we good in terms of I2RS requirements for RESTCONF, if any? > I need to follow up with the I2RS chairs and AD on this one. > > > OK > >> - section 1 >> RESTCONF is based on HTTP1.1 [RFC7230] >> What about HTTP2 [RFC7540]? >> I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2. >> A few words are necessary IMO. >> background:https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html >> I see in section 2.1 >> No other versions of HTTP are supported for use with RESTCONF. >> Do you mean: >> No other versions than HTTP 1.1 are supported for use with RESTCONF. >> So: >> HTTP2.0 MUST NOT be used with RESTCONF. >> If this is the case, some sort of justification is required. >> > You have to say something about HTTP2 > > > > The WG needs to decide what to say, and what section needs to be updated. > There is a lot of text that cites HTTP 1.1. > > I would prefer a small number of edits; MUST support HTTP 1.1; MAY > support HTTP/2 > > > > >> - section 1.1.3 >> non-presence container (or NP-container) >> presence container (or P-container) >> >> As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review: >> >> LM: "non-presence container" is not defined anywhere in the document. >> I can assume that it refers to a container that does not have a >> "presence" statement. If it is, it could be good to: >> define the term in the section 3 and to extend the existing text in >> the section 7.5.5 >> > The idea is to refer to the definitions in RFC6020bis, now that > they have been introduced: > > container: An interior data node that exists in at most one > instance in the data tree. A container has no value, but rather a > set of child nodes. > > o non-presence container: A container that has no meaning of its > own, existing only to contain child nodes. > > o presence container: A container where the presence of the > container itself carries some meaning. > > own, existing only to contain child nodes. > >> > > > I removed terms that were not actually used in draft-13 ok. > > > >> - "Last-Modified" >> This is one of those topics whose requirements are all over the place. This is confusing (at least to me) > > > > You are right. It needs more work. > I want to make sure we can support datastore-specific timestamps and > entity tags > for ephemeral and other datastores. > > > > > RT Last-Modified ETag > > API none none > > Operation none none > > Datastore SHOULD MUST > > Data MAY SHOULD > > restconf-state/capabilities MAY SHOULD > > > (Examples show Last-Modified returned for API) > >> Section 3.4.1.1 >> The last change time is maintained and the "Last-Modified" >> ([RFC7232], Section 2.2 >> ) header is returned in the response for a >> retrieval request. The "If-Unmodified-Since" header can be used in >> edit operation requests to cause the server to reject the request if >> the resource has been modified since the specified timestamp. > > > edit detection > >> Section 3.5 >> For configuration data resources, the server MAY maintain a last- >> modified timestamp for the resource, and return the "Last-Modified" >> header when it is retrieved with the GET or HEAD methods. > > > data resource > >> Section 9.1 >> The server MUST maintain a last-modified timestamp for this >> container, and return the "Last-Modified" header when this data node >> is retrieved with the GET or HEAD methods. > > > > /restconf-state/capabilities (this is MAY/SHOULD in draft-14) > >> Section 10.1 >> The server MUST maintain a last-modified timestamp for this >> container, and return the "Last-Modified" header when this data node >> is retrieved with the GET or HEAD methods. > > > > this was removed in draft-14 > >> Section 10.1.1 >> The server SHOULD maintain a last-modified timestamp for each >> instance of this list entry, and return the "Last-Modified" header >> when this data node is retrieved with the GET or HEAD methods. > > > > this was removed in draft-14 > >> and potentially some more sections > > > > I checked but cannot find more > >> At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained. > This one has been addressed? > > done (in -15) > >> Same remark for entity-tag and section 3.4.1.2 > And this one? > > > > done (in -15) > >> - Section 3.6 >> OLD: >> If the "rpc" or "action" statement has an "input" section, then a >> message-body MAY be sent by the client in the request, otherwise the >> request message MUST NOT include a message-body. If the "input" >> objcet tree contains mandatory parameters, then a message-body MUST >> be sent by the client. >> >> NEW: >> >> If the "rpc" or "action" statement has an "input" section and the >> "input" object tree contains mandatory parameters, then a message-body >> MUST be sent by the client in the request. >> >> If the "rpc" or "action" statement has an "input" section and the >> "input" object tree doesn't contain mandatory parameters, then a message-body >> MAY be sent by the client in the request. >> >> If the "rpc" or "action" statement has no "input" section, the >> request message MUST NOT include a message-body. > > > > this edit is done except exact replacement text not used. > Will be modified in -15 related to Dale's comments. > > If the "rpc" or "action" statement has an "output" section then > instances of these_input _parameters are encoded in the module > namespace where the "rpc" or "action" statement is defined, in an XML > element or JSON object named "output". > > > > fixed cut-and-paste 'input' (in -15) > > > Input or output? > >> - RFC5277 is a normative reference. >> I guess that pub/sub will obsolete RFC5277. >> So we would have to update this RESTCONF RFC-to-be with the pub/sub publication? > And the answer is? > > > > I certainly do not agree that RFC 5277 is going to be obsolete. > Adding new features should not make existing deployed functionality > obsolete. > IMO, the new work must update 5277, not replace it. ok, thanks. > > >> - 5.3.2 Json MetaData Encoding Example >> Note thatRFC 6243 defines the "default" attribute with XSD, not >> YANG, so_the YANG module name has to be assigned manually_. The value >> "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding. >> >> I don't understand "_the YANG module name has to be assigned manually_" > And I still don't understand. Care to reply? > > > > > fixed (in -15) > assigned instead of derived from a YANG module name. > >> >> >> - >> Since we have many examples around around example-jukebox, this should pass compilation, right? >> >> pyang --ietf example-jukebox.yang > > > > > I disagree that --ietf should be added to the validation of > non-normative modules. > >> example-jukebox.yang:1: error: expected keyword "namespace" as child to "module" >> example-jukebox.yang:1: error: expected keyword "prefix" as child to "module" >> example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement >> >> What was the agreed convention for example modules that should pass compilation? > care to reply? > >> - Security Considerations. >> Please includehttps://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines > > > this was done in -14 Ok, I guess that none of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments Btw, should we update https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines now that we will have RESTCONF next to NETCONF. I guess so. Regards, Benoit > > >> >> Regards, Benoit (OPS AD) >> >> >> > > > > Andy --------------030B8D595DE2286131B6DBBF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Andy,



On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear authors,

Thanks for this new draft. I removed the points that are integrated.
Note: I wished that the authors had replied with the points (not) addressed, instead of me spending a couple of hours reviewing all comments and diffs.

First of, there is an issue with the YANG module extraction
xym.py draft-ietf-netconf-restconf-14.txt
ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module' statement within another module
Created the following models::
   example-ops.yang
   example-actions.yang
   example-jukebox.yang
   example-mod.yang

I did not get any YANG errors in idnits.
Investigating with Henrik.
It is true that we validate the example modules without the --ietf option.
IMO, this MUST only be for modules enclosed in <CODE BEGINS> <CODE ENDS>

I don't complain about the examples.
The issue is https://github.com/xym-tool/xym/issues/5
We never resolved the issue of <EXAMPLE-BEGINS> <EXAMPLE-ENDS>
There was no consensus that it was needed or how to do it.
So let's decide now.





Not an issue with the draft, but with the xym.py that can't deal with a module example in a description:
container operations {
           description
             "Container for all operation resources
              (application/yang-operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.
              For example, the 'system-restart' RPC operation defined
              in the 'ietf-system' module would be represented as
              an empty leaf in the 'ietf-system' namespace. This is
              a conceptual leaf, and will not actually be found in
              the module:

                 module ietf-system {                        <=====
                   leaf system-reset {
                     type empty;
                   }
                 }
 
Bug filed for xym.py
Testing https://github.com/donaldh/yang-extractor (which I learned of today), it works fine on this draft.
Currently testing the other drafts.

See in-line.
Dear all,

Here is my draft-ietf-netconf-restconf-13 AD review
[sorry for the delay, it took longer than expected].
If some of the points have already been discussed, let me know.

- https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue
There are still open issues. I would have expected that all issues are closed. Should I be worried?    
- From the charter:
   The RESTCONF work will consider requirements suggested by the other working groups 
   (for example I2RS).

Are we good in terms of I2RS requirements for RESTCONF, if any?
I need to follow up with the I2RS chairs and AD on this one.

OK
 
- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]? 
I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html
I see in section 2.1
   No other versions of HTTP are supported for use with RESTCONF.
Do you mean:
   No other versions than HTTP 1.1 are supported for use with RESTCONF.
So:
   HTTP2.0 MUST NOT be used with RESTCONF.
If this is the case, some sort of justification is required.
You have to say something about HTTP2


The WG needs to decide what to say, and what section needs to be updated.
There is a lot of text that cites HTTP 1.1.

I would prefer a small number of edits; MUST support HTTP 1.1; MAY support HTTP/2




 
- section 1.1.3
non-presence container (or NP-container)
presence container (or P-container)

As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review:

LM: "non-presence container" is not defined anywhere in the document.
    I can assume that it refers to a container that does not have a 
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in 
    the section 7.5.5
The idea is to refer to the definitions in RFC6020bis, now that they have been introduced:
container: An interior data node that exists in at most one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

   o  presence container: A container where the presence of the
      container itself carries some meaning.

      own, existing only to contain child nodes.



I removed terms that were not actually used in draft-13
ok.


 
- "Last-Modified"
This is one of those topics whose requirements are all over the place. This is confusing (at least to me)


You are right.  It needs more work.
I want to make sure we can support datastore-specific timestamps and entity tags
for ephemeral and other datastores.




    RT                                   Last-Modified              ETag

    API                                       none                      none

    Operation                              none                    none

    Datastore                               SHOULD            MUST

    Data                                        MAY                   SHOULD

    restconf-state/capabilities      MAY                    SHOULD


(Examples show Last-Modified returned for API)

Section 3.4.1.1 
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section 2.2) header is returned in the response for a
   retrieval request.  The "If-Unmodified-Since" header can be used in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

edit detection
 
Section 3.5
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods.

data resource
 
Section 9.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this data node
   is retrieved with the GET or HEAD methods.


/restconf-state/capabilities  (this is MAY/SHOULD in draft-14)

 
Section 10.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this data node
   is retrieved with the GET or HEAD methods.


this was removed in draft-14
 
Section 10.1.1
   The server SHOULD maintain a last-modified timestamp for each
   instance of this list entry, and return the "Last-Modified" header
   when this data node is retrieved with the GET or HEAD methods.


this was removed in draft-14
 
and potentially some more sections


I checked but cannot find more

 
At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained.
This one has been addressed?
 
 
done (in -15)
 
Same remark for entity-tag and section 3.4.1.2
And this one?


done  (in -15)

 
- Section 3.6
OLD:
   If the "rpc" or "action" statement has an "input" section, then a
   message-body MAY be sent by the client in the request, otherwise the
   request message MUST NOT include a message-body.  If the "input"
   objcet tree contains mandatory parameters, then a message-body MUST
   be sent by the client. 

NEW:

   If the "rpc" or "action" statement has an "input" section and the 
   "input" object tree contains mandatory parameters, then a message-body 
   MUST be sent by the client in the request. 

   If the "rpc" or "action" statement has an "input" section and the 
   "input" object tree doesn't contain mandatory parameters, then a message-body 
   MAY be sent by the client in the request. 
   
   If the "rpc" or "action" statement has no "input" section, the
   request message MUST NOT include a message-body.



this edit is done except exact replacement text not used.
Will be modified in -15 related to Dale's comments.

 
   If the "rpc" or "action" statement has an "output" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is defined, in an XML
   element or JSON object named "output".


fixed cut-and-paste 'input' (in -15)


 
Input or output?

- RFC5277 is a normative reference. 
I guess that pub/sub will obsolete RFC5277.
So we would have to update this RESTCONF RFC-to-be with the pub/sub publication?
And the answer is?


I certainly do not agree that RFC 5277 is going to be obsolete. 
Adding new features should not make existing deployed functionality obsolete.
IMO, the new work must update 5277, not replace it.
ok, thanks.

 
 - 5.3.2 Json MetaData Encoding Example
   Note that RFC 6243 defines the "default" attribute with XSD, not
   YANG, so the YANG module name has to be assigned manually.  The value
   "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding.

I don't understand "the YANG module name has to be assigned manually"
And I still don't understand. Care to reply?



fixed (in -15)
assigned instead of derived from a YANG module name.

 
  

- 
Since we have many examples around around example-jukebox, this should pass compilation, right? 

pyang --ietf example-jukebox.yang



I disagree that --ietf should be added to the validation of non-normative modules.

 
example-jukebox.yang:1: error: expected keyword "namespace" as child to "module"
example-jukebox.yang:1: error: expected keyword "prefix" as child to "module"
example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-"
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement

What was the agreed convention for example modules that should pass compilation?
care to reply?

this was done in -14
Ok, I guess that none of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments

Btw, should we update https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines now that we will have RESTCONF next to NETCONF. I guess so.

Regards, Benoit


 

Regards, Benoit (OPS AD)




Andy
 

--------------030B8D595DE2286131B6DBBF-- From nobody Sat Jul 2 09:15:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4657C12D103 for ; Sat, 2 Jul 2016 09:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6f3e_ONKD0a for ; Sat, 2 Jul 2016 09:15:34 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B4212D0BA for ; Sat, 2 Jul 2016 09:15:34 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id m127so128403464vkb.3 for ; Sat, 02 Jul 2016 09:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=84q7LdP1QOOwtnJq8oodW+RKevjh56h67G7ScFl6E98=; b=qvIt2W//GJCmxRHJfROsSH/M4YYO6YuSRIg1B9l/DAt2glkHmUnuRPHI0ighDw+dqq dazwodqHvrYI4ddBf0NmQkhQbCymbphq5vAtMTNwf1H6pm3CfdCcRBKl4d4c/6iFBorq ZwbfC/OZCcy3QElr69/BdUCyq/ecRnaL6m0TsXT4t8VA8acrwaOdIartONv2ARJEC4vJ fS/EimQ7LrS+Ydl8SJBpf3dOJ6wG/GrqsHIcNMZqQ9QQnX8ma/H1mPPEkLL0cv5NqOZu u9AJMYr+k9JUCf/IVMqZnZ7hq46NEw6BiCCYxgvIk6MKJ3gdjPGHixDs5zhroH0srwRh 8MkQ== 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; bh=84q7LdP1QOOwtnJq8oodW+RKevjh56h67G7ScFl6E98=; b=mX6kmk3OJoao8vjck2uyFeUcgzHo1OsY4o8aQdP14WDCLVeKBrw/tqcnHOK6jI/Gu8 drzVB0DXNMZgEjW0bt8IgAcFc1xsfSRacga1ysSzkmmSIxX5mZUP/1HzbIVpdH57+6Ek iRZDL+VznBmRyMrIyOmAGehhLwJikQC8rYPDMSS/SWzKJ+L99Fj09Vq/EJmR1rCpZL2R B6p1S5lqFo0b/rdry/sTGfffs/MPmSSKWAMCmUsrNdVzxA3gqyN5EW4bTsG0H+2gfM6Q m5s/Jw2oDboXObACdrv9pa6W06UGu6mV7FMoJ3MNe/KGFtk82lbll0xbzPK0uYIXuJ7p U5Qg== X-Gm-Message-State: ALyK8tLtO6PT0rlpuUZlxhGNCiPao8lhlb0DSDqjMdog4KdaOVoIgdcAgatSyraG1R0IGYgIKpxCHCa+vfOUAw== X-Received: by 10.31.4.4 with SMTP id 4mr1810389vke.121.1467476133273; Sat, 02 Jul 2016 09:15:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Sat, 2 Jul 2016 09:15:31 -0700 (PDT) In-Reply-To: References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> From: Andy Bierman Date: Sat, 2 Jul 2016 09:15:31 -0700 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a114298c8a3f8210536a969a1 Archived-At: Cc: NETCONF Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 16:15:38 -0000 --001a114298c8a3f8210536a969a1 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 2, 2016 at 1:31 AM, Benoit Claise wrote: > Hi Andy, > > > > On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise wrote: > >> Dear authors, >> >> Thanks for this new draft. I removed the points that are integrated. >> Note: I wished that the authors had replied with the points (not) >> addressed, instead of me spending a couple of hours reviewing all comments >> and diffs. >> >> First of, there is an issue with the YANG module extraction >> >> xym.py draft-ietf-netconf-restconf-14.txt >> ERROR: 'draft-ietf-netconf-restconf-14.txt', Line 3930 - 'module' >> statement within another module >> Created the following models:: >> example-ops.yang >> example-actions.yang >> example-jukebox.yang >> example-mod.yang >> >> > I did not get any YANG errors in idnits. > > Investigating with Henrik. > > It is true that we validate the example modules without the --ietf option. > IMO, this MUST only be for modules enclosed in > > I don't complain about the examples. > The issue is https://github.com/xym-tool/xym/issues/5 > > We never resolved the issue of > There was no consensus that it was needed or how to do it. > So let's decide now. > > > > > > Not an issue with the draft, but with the xym.py that can't deal with a >> module example in a description: >> >> container operations { >> description >> "Container for all operation resources >> (application/yang-operation), >> >> Each resource is represented as an empty leaf with the >> name of the RPC operation from the YANG rpc statement. >> For example, the 'system-restart' RPC operation defined >> in the 'ietf-system' module would be represented as >> an empty leaf in the 'ietf-system' namespace. This is >> a conceptual leaf, and will not actually be found in >> the module: >> >> module ietf-system { <===== >> leaf system-reset { >> type empty; >> } >> } >> >> >> >> Bug filed for xym.py >> Testing https://github.com/donaldh/yang-extractor (which I learned of >> today), it works fine on this draft. >> Currently testing the other drafts. >> >> See in-line. >> >> Dear all, >> >> Here is my draft-ietf-netconf-restconf-13 AD review >> [sorry for the delay, it took longer than expected]. >> If some of the points have already been discussed, let me know. >> >> - https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue >> There are still open issues. I would have expected that all issues are closed. Should I be worried? >> >> - From the charter: >> The RESTCONF work will consider requirements suggested by the other working groups >> (for example I2RS). >> >> Are we good in terms of I2RS requirements for RESTCONF, if any? >> >> I need to follow up with the I2RS chairs and AD on this one. >> > > OK > > >> - section 1 >> RESTCONF is based on HTTP1.1 [RFC7230] >> What about HTTP2 [RFC7540]? >> I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2. >> A few words are necessary IMO. >> background: https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html >> I see in section 2.1 >> No other versions of HTTP are supported for use with RESTCONF. >> Do you mean: >> No other versions than HTTP 1.1 are supported for use with RESTCONF. >> So: >> HTTP2.0 MUST NOT be used with RESTCONF. >> If this is the case, some sort of justification is required. >> >> >> You have to say something about HTTP2 >> > > > The WG needs to decide what to say, and what section needs to be updated. > There is a lot of text that cites HTTP 1.1. > > I would prefer a small number of edits; MUST support HTTP 1.1; MAY support > HTTP/2 > > > > > > >> - section 1.1.3 >> non-presence container (or NP-container) >> presence container (or P-container) >> >> As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review: >> >> LM: "non-presence container" is not defined anywhere in the document. >> I can assume that it refers to a container that does not have a >> "presence" statement. If it is, it could be good to: >> define the term in the section 3 and to extend the existing text in >> the section 7.5.5 >> >> The idea is to refer to the definitions in RFC6020bis, now that they have >> been introduced: >> >> container: An interior data node that exists in at most one >> instance in the data tree. A container has no value, but rather a >> set of child nodes. >> >> o non-presence container: A container that has no meaning of its >> own, existing only to contain child nodes. >> >> o presence container: A container where the presence of the >> container itself carries some meaning. >> >> own, existing only to contain child nodes. >> >> >> >> > > I removed terms that were not actually used in draft-13 > > ok. > > > > > >> - "Last-Modified" >> This is one of those topics whose requirements are all over the place. This is confusing (at least to me) >> >> > > You are right. It needs more work. > I want to make sure we can support datastore-specific timestamps and > entity tags > for ephemeral and other datastores. > > > > > RT Last-Modified ETag > > API none > none > > Operation none none > > Datastore SHOULD MUST > > Data MAY > SHOULD > > restconf-state/capabilities MAY SHOULD > > > (Examples show Last-Modified returned for API) > > Section 3.4.1.1 >> The last change time is maintained and the "Last-Modified" >> ([RFC7232], Section 2.2 ) header is returned in the response for a >> retrieval request. The "If-Unmodified-Since" header can be used in >> edit operation requests to cause the server to reject the request if >> the resource has been modified since the specified timestamp. >> >> > edit detection > > >> Section 3.5 >> For configuration data resources, the server MAY maintain a last- >> modified timestamp for the resource, and return the "Last-Modified" >> header when it is retrieved with the GET or HEAD methods. >> >> > data resource > > >> Section 9.1 >> The server MUST maintain a last-modified timestamp for this >> container, and return the "Last-Modified" header when this data node >> is retrieved with the GET or HEAD methods. >> >> > > /restconf-state/capabilities (this is MAY/SHOULD in draft-14) > > > >> Section 10.1 >> The server MUST maintain a last-modified timestamp for this >> container, and return the "Last-Modified" header when this data node >> is retrieved with the GET or HEAD methods. >> >> > > this was removed in draft-14 > > >> Section 10.1.1 >> The server SHOULD maintain a last-modified timestamp for each >> instance of this list entry, and return the "Last-Modified" header >> when this data node is retrieved with the GET or HEAD methods. >> >> > > this was removed in draft-14 > > >> and potentially some more sections >> >> > > I checked but cannot find more > > > >> At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained. >> >> This one has been addressed? >> > > > done (in -15) > > >> Same remark for entity-tag and section 3.4.1.2 >> >> And this one? >> > > > done (in -15) > > > >> - Section 3.6 >> OLD: >> If the "rpc" or "action" statement has an "input" section, then a >> message-body MAY be sent by the client in the request, otherwise the >> request message MUST NOT include a message-body. If the "input" >> objcet tree contains mandatory parameters, then a message-body MUST >> be sent by the client. >> >> NEW: >> >> If the "rpc" or "action" statement has an "input" section and the >> "input" object tree contains mandatory parameters, then a message-body >> MUST be sent by the client in the request. >> >> If the "rpc" or "action" statement has an "input" section and the >> "input" object tree doesn't contain mandatory parameters, then a message-body >> MAY be sent by the client in the request. >> >> If the "rpc" or "action" statement has no "input" section, the >> request message MUST NOT include a message-body. >> >> >> > > this edit is done except exact replacement text not used. > Will be modified in -15 related to Dale's comments. > > > >> If the "rpc" or "action" statement has an "output" section then >> instances of these *input *parameters are encoded in the module >> namespace where the "rpc" or "action" statement is defined, in an XML >> element or JSON object named "output". >> >> > > fixed cut-and-paste 'input' (in -15) > > > > >> Input or output? >> >> - RFC5277 is a normative reference. >> I guess that pub/sub will obsolete RFC5277. >> So we would have to update this RESTCONF RFC-to-be with the pub/sub publication? >> >> And the answer is? >> > > > I certainly do not agree that RFC 5277 is going to be obsolete. > Adding new features should not make existing deployed functionality > obsolete. > IMO, the new work must update 5277, not replace it. > > ok, thanks. > > > > >> - 5.3.2 Json MetaData Encoding Example >> >> Note that RFC 6243 defines the "default" attribute with XSD, not >> YANG, so *the YANG module name has to be assigned manually*. The value >> "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding. >> >> I don't understand "*the YANG module name has to be assigned manually*" >> >> And I still don't understand. Care to reply? >> >> > > > fixed (in -15) > assigned instead of derived from a YANG module name. > > > >> >> >> - >> Since we have many examples around around example-jukebox, this should pass compilation, right? >> >> pyang --ietf example-jukebox.yang >> >> > > > I disagree that --ietf should be added to the validation of non-normative > modules. > > > >> example-jukebox.yang:1: error: expected keyword "namespace" as child to "module" >> example-jukebox.yang:1: error: expected keyword "prefix" as child to "module" >> example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement >> example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement >> >> What was the agreed convention for example modules that should pass compilation? >> >> care to reply? >> > - Security Considerations. >> Please include https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines >> >> > this was done in -14 > > Ok, I guess that none of the readable data nodes in this YANG module may > be considered sensitive or vulnerable in some network environments > Kent and I discussed whether the list of operation names retrieved under /restconf/operations was a threat, but we decided it wasn't because all the information can be derived from the YANG library contents. > > Btw, should we update > https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines > now that we will have RESTCONF next to NETCONF. I guess so. > > Regards, Benoit > Andy > > > > >> Regards, Benoit (OPS AD) >> >> >> >> >> > > > Andy > > > > --001a114298c8a3f8210536a969a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 2, 2016 at 1:31 AM, Benoit Claise <bclaise@cisco.com&g= t; wrote:
=20 =20 =20
Hi Andy,

=20


On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear authors,

Thanks for this new draft. I removed the points that are integrated.
Note: I wished that the authors had replied with the points (not) addressed, instead of me spending a couple of hours reviewing all comments and diffs.

First of, there is an issue with the YANG module extraction
xym.py draft-ietf-netconf-restconf-14.txt
ERROR: 'draft-ietf-netconf-restconf-14.txt', Li= ne 3930 - 'module' statement within another module=
Created the following models::
=C2=A0=C2=A0 example-ops.yang
=C2=A0=C2=A0 example-actions.yang
=C2=A0=C2=A0 example-jukebox.yang
=C2=A0=C2=A0 example-mod.yang

I did not get any YANG errors in idnits.
Investigating with Henrik.
It is true that we validate the example modules without the --ietf option.
IMO, this MUST only be for modules enclosed in <CODE BEGINS> <CODE ENDS>

I don't complain about the examples.
The issue is https://github.com/xym-tool/xym/issues/5
We never resolved the issue of <EXAMPLE-BEGINS> <EXAMPLE-ENDS>
There was no consensus that it was needed or how to do it.
So let's decide now.





Not an issue with the draft, but with the xym.py that can't deal with a module example in a description: 
container operations {
           description
             "Container for all operation resources
              (application/yang-operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.
              For example, the 'system-restart' RPC operation defin=
ed
              in the 'ietf-system' module would be represented as
              an empty leaf in the 'ietf-system' namespace. This is
              a conceptual leaf, and will not actually be found in
              the module:

                 module ietf-system {                        <=3D=3D=3D=
=3D=3D
                   leaf system-reset {
                     type empty;
                   }
                 }
=C2=A0
Bug filed for xym.py
Testing https://github.com/donaldh/yang-extractor (which I learned of today), it works fine on this draft.
Currently testing the other drafts.

See in-line.
Dear all,

Here is my draft-ietf-netconf-restconf-13 AD review
[sorry for the delay, it took longer than expected]. If some of the points have already been discussed, let me know.

- https://github.com/n=
etconf-wg/restconf/issues?q=3Dis%3Aopen+is%3Aissue
There are still open issues. I would have expected that all issues are clos=
ed. Should I be worried?    
- From the charter:
   The RESTCONF work will consider requirements suggested by the other work=
ing groups=20
   (for example I2RS).

Are we good in terms of I2RS requirements for RESTCONF, if any?
I need to follow up with the I2RS chairs and AD on this one.

OK
=C2=A0
- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]?=20
I've seen some discussions on the NETCONF mailing but I'm unclear i=
f RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/web/ne=
tconf/current/msg08578.html
I see in section 2.1
   No other versions of HTTP are supported for use with RESTCONF.
Do you mean:
   No other versions than HTTP 1.1 are supported for use with RESTCONF.
So:
   HTTP2.0 MUST NOT be used with RESTCONF.
If this is the case, some sort of justification is required.
You have to say something about HTTP2


The WG needs to decide what to say, and what section needs to be updated.
There is a lot of text that cites HTTP 1.1.

I would prefer a small number of edits; MUST support HTTP 1.1; MAY support HTTP/2




=C2=A0
- section 1.1.3
non-presence container (or NP-container)
presence container (or P-container)

As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 r=
eview:

LM: "non-presence container" i=
s not defined anywhere in the document.
    I can assume that it refers to a container that does not have a=20
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in=20
    the section 7.5.5
The idea is to refer to the definitions in RFC6020bis, now that they have been introduced:
container: An interior data node that exists in at mos=
t one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

   o  presence container: A container where the presence of the
      container itself carries some meaning.

      own, existing only to contain child nodes.



I removed terms that were not actually used in draft-13
ok.


=C2=A0
- "Last-Modified"
This is one of those topics whose requirements are all over the place. This=
 is confusing (at least to me)


You are right.=C2=A0 It needs more work.
I want to make sure we can support datastore-specific timestamps and entity tags
for ephemeral and other datastores.




=C2=A0 =C2=A0 RT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Last-Modified =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ETag

=C2=A0 =C2=A0 API =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 none =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0none

=C2=A0 =C2=A0 Operation =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0none = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0none

=C2=A0 =C2=A0 Datastore =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOU= LD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST

=C2=A0 =C2=A0 Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD

=C2=A0 =C2=A0 restconf-state/capabilities =C2=A0 =C2=A0 = =C2=A0MAY =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD


(Examples show Last-Modified returned for API)

Section 3.4.1.1=20
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section=C2=A02.2) header is returned in the response =
for a
   retrieval request.  The "If-Unmodified-Since" header can be us=
ed in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

edit detection
=C2=A0
Section 3.5
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified&=
quot;
   header when it is retrieved with the GET or HEAD methods.

data resource
=C2=A0
Section 9.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this dat=
a node
   is retrieved with the GET or HEAD methods.


/restconf-state/capabilities =C2=A0(this is MAY/SHOULD in draft-14)

=C2=A0
Section 10.1
   The server MUST maintain a last-modified timestamp for this
   container, and return the "Last-Modified" header when this dat=
a node
   is retrieved with the GET or HEAD methods.


this was removed in draft-14
=C2=A0
Section 10.1.1
   The server SHOULD maintain a last-modified timestamp for each
   instance of this list entry, and return the "Last-Modified" he=
ader
   when this data node is retrieved with the GET or HEAD methods.


this was removed in draft-14
=C2=A0
and potentially some more sections


I checked but cannot find more

=C2=A0
At the minimum, we should have forward ref=
erences from section 3.4.1.1 as it looks like self-contained.
This one has been addressed?
=C2=A0
=C2=A0
done (in -15)
=C2=A0
Same remark for entity-tag and section 3.4=
.1.2
And this one?


done =C2=A0(in -15)

=C2=A0
- Section 3.6
OLD:
   If the "rpc" or "action" statement has an "inpu=
t" section, then a
   message-body MAY be sent by the client in the request, otherwise the
   request message MUST NOT include a message-body.  If the "input&quo=
t;
   objcet tree contains mandatory parameters, then a message-body MUST
   be sent by the client.=20

NEW:

   If the "rpc" or "action" statement has an "inpu=
t" section and the=20
   "input" object tree contains mandatory parameters, then a mess=
age-body=20
   MUST be sent by the client in the request.=20

   If the "rpc" or "action" statement has an "inpu=
t" section and the=20
   "input" object tree doesn't contain mandatory parameters, =
then a message-body=20
   MAY be sent by the client in the request.=20
  =20
   If the "rpc" or "action" statement has no "inpu=
t" section, the
   request message MUST NOT include a message-body.



this edit is done except exact replacement text not used.
Will be modified in -15 related to Dale's comments.

=C2=A0
   If the "rpc" or "action" statem=
ent has an "output" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is d=
efined, in an XML
   element or JSON object named "output".


fixed cut-and-paste 'input' (in -15)


=C2=A0
Input or output?

- RFC5277 is a normative reference.=20
I guess that pub/sub will obsolete RFC5277.
So we would have to update this RESTCONF RFC-to-be with the pub/sub publica=
tion?
And the answer is?


I certainly do not agree that RFC 5277 is going to be obsolete.=C2=A0
Adding new features should not make existing deployed functionality obsolete.
IMO, the new work must update 5277, not replace it.
ok, thanks.

=C2=A0
=C2=A0- 5.3.2 Json MetaData Encoding Examp=
le
   Note that RFC 6243 defines the "default=
" attribute with XSD, not
   YANG, so the YANG module name has to be assigned manually.  The v=
alue
   "ietf-netconf-with-defaults" is assigned for JSON meta-data en=
coding.

I don't understand "the YANG module name has to be assigned man=
ually"
And I still don't understand. Care to reply?



fixed (in -15)
assigned instead of derived from a YANG module name.

=C2=A0
 =20

-=20
Since we have many examples around around example-jukebox, this should pass=
 compilation, right?=20

pyang --ietf example-jukebox.yang



I disagree that --ietf should be added to the validation of non-normative modules.

=C2=A0
example-jukebox.yang:1: error: expected ke=
yword "namespace" as child to "module"
example-jukebox.yang:1: error: expected keyword "prefix" as child=
 to "module"
example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should star=
t with one of the strings "ietf-" or "iana-"
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "contact" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "organization" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "description" substatement
example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" =
must have a "revision" substatement

What was the agreed convention for example modules that should pass compila=
tion?
care to reply?

this was done in -14
Ok, I guess that none of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments



Kent and I= discussed whether the list of operation names retrieved under /restconf/op= erations
was a threat, but we decided it wasn't because all t= he information can be derived from
the YANG library contents.

=C2=A0

Btw, should we update https://trac.tools.ietf.org/area/ops/trac/wi= ki/yang-security-guidelines now that we will have RESTCONF next to NETCONF. I guess so.

Regards, Benoit


Andy
=C2=A0


=C2=A0
Regards, Benoit (OPS AD)




Andy
=C2=A0


--001a114298c8a3f8210536a969a1-- From nobody Sun Jul 3 09:17:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63F12D0A4 for ; Sun, 3 Jul 2016 09:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kszVaAV3uTgy for ; Sun, 3 Jul 2016 09:17:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D612B04F for ; Sun, 3 Jul 2016 09:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6274; q=dns/txt; s=iport; t=1467562667; x=1468772267; h=from:to:subject:date:message-id:mime-version; bh=F2k4PgGIR9k4gPmPH+FsamUQwlhEPJVa+CY6SEDjWbw=; b=GyVN4MHtl5XAWxJ1GuE1J0b+k1ZlT2Fwhq3ljPZLB6GyvX1L8ZJtxYN3 AuXkP1KWVhk+h+9JL7xpnvuxz47E40rYjOLtcJyjxZIwTSy3lhhLgtgzJ DvgXAcCTrQU+ANbYV+DX9yGveCA+zLAOi2fjLVR0fS1k7cGe6gxSKCuH4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgDgOXlX/4wNJK1bgnBOVnwGtC+FA?= =?us-ascii?q?YF5JIcZOBQBAQEBAQEBZRwLhFMtXgGBACYBBBuIKA6iPJ8tAQEBAQEBBAEBAQE?= =?us-ascii?q?BAQEbBYYoiHeFcQWIeYpghToBgTCEWIg3jzGQCQEeNoNwbgEBhzN/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,570,1459814400"; d="scan'208,217";a="292288259" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jul 2016 16:17:46 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u63GHkgM004079 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 3 Jul 2016 16:17:46 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 3 Jul 2016 11:17:45 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Sun, 3 Jul 2016 11:17:45 -0500 From: "Steve Truong (struong)" To: "netconf@ietf.org" Thread-Topic: Comments on draft-ietf-netconf-restconf-14 Thread-Index: AdHVRmYMu5WaDK/cRWSaE03fH70eBg== Date: Sun, 3 Jul 2016 16:17:45 +0000 Message-ID: <8740ac1364a54317afc581b63e2f7e3a@XCH-RCD-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.6.216] Content-Type: multipart/alternative; boundary="_000_8740ac1364a54317afc581b63e2f7e3aXCHRCD014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Comments on draft-ietf-netconf-restconf-14 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 16:17:49 -0000 --_000_8740ac1364a54317afc581b63e2f7e3aXCHRCD014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-9.1 The server MAY maintain a last-modified timestamp for this container, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. Note that the last-modified timestamp for the datastore resource is not affected by changes this subtree. Is something missing in the last sentence? Same comment for the next paragraph on ETag. In https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#appendix-D.2.2 D.2.2. Detect Resource Entity Tag Change In this example, the server just supports the mandatory datastore last-changed timestamp. Where is timestamp mandatory in draft version 14? Thanks, steve --_000_8740ac1364a54317afc581b63e2f7e3aXCHRCD014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In

https://tools.ietf.org/html/draft-ietf-ne= tconf-restconf-14#section-9.1

   The server MAY maintain a last-modified timestamp for thi=
s container,
   and return the "Last-Modified" header when this=
 data node is
   retrieved with the GET or HEAD methods.  Note that t=
he last-modified
   timestamp for the datastore resource is not affected by changes this=

   subtree.

 

Is something missing in the last sentence?

Same comment for the next paragraph on ETag.=

 

In

https://tools.ietf.org/html/draft-ietf= -netconf-restconf-14#appendix-D.2.2

D.2.2.  Detect Resource Entity Tag Change

   In this example, the server just supports the mandatory datastore=

   last-changed timestamp.

 

Where is timestamp mandatory in draft version 14?=

 

Thanks,

steve

 

 

--_000_8740ac1364a54317afc581b63e2f7e3aXCHRCD014ciscocom_-- From nobody Mon Jul 4 04:16:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB83127058 for ; Mon, 4 Jul 2016 04:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2v_oAgv1Ss7 for ; Mon, 4 Jul 2016 04:16:10 -0700 (PDT) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2463D12B064 for ; Mon, 4 Jul 2016 04:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:Cc:To:MIME-Version:Sender:Reply-To:Message-ID: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sMGiG03BUVEUUYyJMp+FoSR1J66dIiPPdoD2uuDh26k=; b=Wn5Z8I/ahLai5i6wB7GEBHHQy jARUeJVcVaRxwq9NyxP9yiDH+9w80zdZhAHn7q08VVDm3KAnb0QnPMjmnYCTKXuEqQJNd0b8uz2wx S9VFsHLm+x5W3GIzAxbFHbwqo8nbxVraoagaoH2eE9lKNQW7p8cdjNOpIm6LEZoOxJ7CFa45FPCW1 OLqNOr9RrAqQPgxaiRuIn0nUNSpSAbF7LlY2tuPSaMW+FExGxdAOqP7bifYO90c5TBbsVrR8Wd8eU GH2LGZPmAnPrrBDQnMGFDZ2Dc1tcGVCJrCtrTyKc9zdUT0mDRBPhIPm8lChgakMPF14n9r9/hZae8 jZWIv9UvA==; Received: from host-92-19-235-90.static.as13285.net ([92.19.235.90]:50817 helo=[IPv6:::ffff:192.168.1.220]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bK1rC-001gqH-2N; Mon, 04 Jul 2016 12:16:06 +0100 MIME-Version: 1.0 To: Martin Bjorklund , "alex@cisco.com" From: Jonathan Hansford Date: Mon, 4 Jul 2016 12:24:00 +0100 Importance: normal X-Priority: 3 In-Reply-To: <20160701.125757.71813639576051509.mbj@tail-f.com> References: <20160701.125757.71813639576051509.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="_DF3A4F4A-3AC1-438F-88E5-2C821A19F464_" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Message-Id: <20160704111610.2463D12B064@ietfa.amsl.com> Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Some discussion points re: RFC 5277bis and YANG push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 11:16:13 -0000 --_DF3A4F4A-3AC1-438F-88E5-2C821A19F464_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 From: Martin Bjorklund Sent: 01 July 2016 11:57 To: alex@cisco.com Cc: netconf@ietf.org Subject: Re: [Netconf] Some discussion points re: RFC 5277bis and YANG push Hi, I think this would be a useful feature. It would be harmless in most use cases, and useful in some specific use cases, e.g. generic proxies etc. /martin "Alexander Clemm (alex)" wrote: > Hi, >=20 > draft-gonzalez-netconf-5277bis is another one of the drafts in the set > of drafts concerning event notifications and yang-push. >=20 > One of the items wort bringing for discussion concerns the notion of > control plane notifications that are used to indicate the status of a > notification subscription. Examples of such notifications are > "replayComplete", "subscription-modified" (in case case of configured > subscriptions), and "subscription-suspended" (of particular importance > for draft-ietf-netconf-yang-push, another draft in the set, used by > the server to notify a client in case notification updates cannot be > sent as promised under various rainy-day scenarios). >=20 > What makes those notifications different from other notifications is > that they are not of general concern, but of concern only for a > particular association. As a subscriber to event notifications, I > should only receive those notifications that concern "my" > subscription, not those that concern someone else's subscription. >=20 > The way we are planning to address this is through introduction of an > extension "control-plane-notif". This extension is used to tag > definitions of notifications used for control / signaling purposes > that are therefore not part of the general NETCONF event stream. > Instead, notifications thus tagged are part of a signaling event > stream that is part of the signaling/control association implied by > the subscription. Like push-notifications themselves, there is a need > to distinguish notifications subscribable by everyone and notification > instances used by a server to notify items of significance to a > specific client, or set of clients. Please refer also to section 7 of > the draft > (https://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-02#section-7 > ). >=20 > We have been discussing this issue as part of the weekly calls in > which a subteam of NETCONF WG participants are discussing the set of > of related drafts and think this is one of the issues that we should > bring to the attention of and solicit feedback from the WG as a whole. >=20 > Thoughts? > --- Alex > (on behalf of the team) >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_DF3A4F4A-3AC1-438F-88E5-2C821A19F464_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

+1

 

From: Martin Bjorklund
Sent: 01 July 2016 11:57
To: alex@cisco.com
Cc: netconf@ietf.org
Subject: Re: [Netco= nf] Some discussion points re: RFC 5277bis and YANG push

 

Hi,

 

I think this would be a = useful feature.=C2=A0 It would be harmless in most

= use cases, and useful in some specific use cases, e.g. generic proxies

<= p class=3DMsoNormal>etc.

 

 

/martin

 

 <= /p>

"Alexander Clemm (alex)" <alex@cisco.c= om> wrote:

> Hi,

>=

> draft-gonzalez-netconf-5277bis is another on= e of the drafts in the set

> of drafts concernin= g event notifications and yang-push.

>

> One of the items wort bringing for discussion concerns= the notion of

> control plane notifications tha= t are used to indicate the status of a

> notific= ation subscription.=C2=A0 Examples of such notifications are

> "replayComplete", "subscription-modified"= ; (in case case of configured

> subscriptions), = and "subscription-suspended" (of particular importance

> for draft-ietf-netconf-yang-push, another draft in the s= et, used by

> the server to notify a client in c= ase notification updates cannot be

> sent as pro= mised under various rainy-day scenarios).

>

=

> What makes those notifications different from oth= er notifications is

> that they are not of gener= al concern, but of concern only for a

> particul= ar association.=C2=A0 As a subscriber to event notifications, I

> should only receive those notifications that concern &quo= t;my"

> subscription, not those that concer= n someone else's subscription.

>

> The way we are planning to address this is through introduct= ion of an

> extension "control-plane-notif&= quot;.=C2=A0 This extension is used to tag

> def= initions of notifications used for control / signaling purposes

> that are therefore not part of the general NETCONF event = stream.

> Instead, notifications thus tagged are= part of a signaling event

> stream that is part= of the signaling/control association implied by

&g= t; the subscription.=C2=A0 Like push-notifications themselves, there is a n= eed

> to distinguish notifications subscribable = by everyone and notification

> instances used by= a server to notify items of significance to a

>= specific client, or set of clients.=C2=A0 Please refer also to section 7 o= f

> the draft

> (http= s://tools.ietf.org/html/draft-gonzalez-netconf-5277bis-02#section-7

> ).

>

> We have been discussing this issue as part of the weekly calls in<= /p>

> which a subteam of NETCONF WG participants are= discussing the set of

> of related drafts and t= hink this is one of the issues that we should

> = bring to the attention of and solicit feedback from the WG as a whole.

<= p class=3DMsoNormal>>

> Thoughts?

> --- Alex

> (on behalf of the = team)

>

 

_______________________________________________<= /p>

Netconf mailing list

Netcon= f@ietf.org

https://www.ietf.org/mailman/listinfo/ne= tconf

 

= --_DF3A4F4A-3AC1-438F-88E5-2C821A19F464_-- From nobody Tue Jul 5 08:28:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D672D12D0DC for ; Tue, 5 Jul 2016 08:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEgieJIBgrTA for ; Tue, 5 Jul 2016 08:28:32 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C82212D0AA for ; Tue, 5 Jul 2016 08:28:32 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id bz2so68274680pad.1 for ; Tue, 05 Jul 2016 08:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=53jIqXMIGEN9bZ3VBPuKJ0eHazKD1RGJ8vCioUa2bfM=; b=Buje4QQxp5hQcgJVn5TzVVKa00oEOKAJqY8hPQJmwpJ6rkzVAfWTAhcsSxFLNWBNxB ZNiDMq2fXtroIFH+lc9RNKhmbzQ6XgpDnMkKi38/IAZsKQih5XuuuKe23RT4F0npCQGe Sr+vHcgP5xoO9GBmjokm8j13TYps2fFXMMtjCStQycc/4vPIOretTj1syZzmum25MI4w J+JPfszBRIHLBNLbIhj0xBW8PyU94+DrTif0fIwlQDuUOomIyxNtPag6uAN+6nPGkXBr Pm2Vp4zpYylRo/Oqf400z3OiZBFQ2YjFt8dbDoMbfSmhpIp9yR2szePB+/9I4waDivaD zB+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=53jIqXMIGEN9bZ3VBPuKJ0eHazKD1RGJ8vCioUa2bfM=; b=YSvW4D/PhMdPUxM/yKwz5686EDwvQ2NWUrnReV9b4Jmt6FKgC6M7hAA1M/g+TKHtX6 +ZK9FyfKhM1KnhRYnTIDQ59JJq65quga0KQFgQT90DYY9fNx3hkgrAZF4ljLpgAASt/T v7/PnhZoaXHQJynbpcZFIT5Zgsvj5NR/T2pwEeOeYr22h+kgHETrF4n6C97Zzf8GSB+t ycQtuZ5zxLaa58Jb7BdIWrKn7QyayXRGpJhkYzmCcadIJQZNBOCPi9eozPJFpfm57Oyj ULs3WUQDTGMJQoZMoSl/BYX6jTaK6WkjGYQyyXiM8AZq54bF7sRf0E9BqLNYSkcF/gb5 kDQw== X-Gm-Message-State: ALyK8tK+ASPG73p6GEH9d1moDC/tDzVBQCPhqQEND5kJB+UGFbZwsb0urwsRT2VQGL06sg== X-Received: by 10.66.233.103 with SMTP id tv7mr33005215pac.46.1467732511372; Tue, 05 Jul 2016 08:28:31 -0700 (PDT) Received: from [10.24.36.136] ([128.107.241.171]) by smtp.gmail.com with ESMTPSA id d2sm5846407pfk.36.2016.07.05.08.28.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jul 2016 08:28:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Tue, 5 Jul 2016 08:28:25 -0700 Message-Id: References: To: Netconf , media-types@iana.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netconf] request review of media type application/yang-patch+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 15:28:34 -0000 --Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Andy requested a review on the update to media type registration for = YANG patch. Note, there are two reviews, one for XML and another one for = JSON. Unless we hear otherwise by end of this week, we will go ahead with the = suggested changes. Thanks. > On Jun 28, 2016, at 7:29 PM, Andy Bierman wrote: >=20 > Hi, >=20 > Please review and provide feedback on the media type registration > for YANG Patch media type for the PATCH method. This is used by > the RESTCONF protocol. >=20 >=20 > = https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1= = >=20 >=20 > thanks, > Andy Mahesh & Mehmet --Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Andy requested a review on the update to media type = registration for YANG patch. Note, there are two reviews, one for XML = and another one for JSON.

Unless we hear otherwise by end of this week, we will go = ahead with the suggested changes.

Thanks.
On = Jun 28, 2016, at 7:29 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

Please = review and provide feedback on the media type registration
for  YANG Patch media type = for the PATCH method.  This is used by
the RESTCONF protocol.


https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#se= ction-4.2.1


thanks,
Andy

Mahesh & Mehmet





= --Apple-Mail=_7D1622C5-6039-41D7-AB3E-A635B7A62945-- From nobody Tue Jul 5 09:57:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4038B12D528 for ; Tue, 5 Jul 2016 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNicplhxvjLB for ; Tue, 5 Jul 2016 09:57:44 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B3712D523 for ; Tue, 5 Jul 2016 09:57:44 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id v6so2743374vkb.2 for ; Tue, 05 Jul 2016 09:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8zW7yRijyJzhku/hHyQjFeOCWtm1ByB4aSO84WHT9Og=; b=zM74Xwix1weFhlwmmps0e+bPxw5+YgqnOyKY6/IZZ4VK6oaJWRicb7wCEpUnxpMuwW xFKneVhFe2v9Cmh/iiN8lF+0rr3ICvUMojGg2WKT+ksMwnnK1XTdQoqpILZzQJjfktAN je85NJoOhscDcwREPXx6zs9D8YqF91p/Kd2zGRJoeEueOQdtCVoJb6NF2kqaggqet6rs WrcXvI4nkF5Sc+lSv1JjWf9tfR3Hv6Xbk/kMsMbO+68aAQee2qN03EBU4fGWrnhCQgPs MfhYzbjXe45Gq5b5eaKie6mQJTohxoYXYVhC5RLYUbRSoc0TRKlITqcmTbjzmx/h97mK 5jmg== 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; bh=8zW7yRijyJzhku/hHyQjFeOCWtm1ByB4aSO84WHT9Og=; b=b+f91wWrQCSVaIDYrsFMKi+bgUFTsoCktko/55bR2CWNCl3kAODTlQHShnF+0uCxi3 CAjaTSjS72o3aHU9fQyJbKmp4IzcoIttUIIWD5vp86ePMxQbdUAKqzDpoM/nGj7Ehweo ce/WjzUPKEJugjeg/poudaRvN/MLRGbjiKmWuB+TJGozucwjxSBnnWZTsBSg78tLbpna m4eemvp/WgmnyN1OTYxduBI4W/IBwgiDpHjAGoBuDc8vsq8ZoGHQ6rwlVJXKfJMGzSUS VfUDsZUlwV1sWZ0vmZ9WvdHVxhaHgeSPUKPPglbjQSJ8x/YbOCIMSatNd3ZUJupCYZXc dcYg== X-Gm-Message-State: ALyK8tJ7ORII/mlnOkJtmyguoymR/PZemVIvl+cuy+z3a3myijBGoqLyvBk1FG4stSF02YXDOI2QZRgtgg/olg== X-Received: by 10.31.60.204 with SMTP id j195mr7766855vka.132.1467737863619; Tue, 05 Jul 2016 09:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 5 Jul 2016 09:57:42 -0700 (PDT) In-Reply-To: <20160701.103113.301947010745595267.mbj@tail-f.com> References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> <20160701.103113.301947010745595267.mbj@tail-f.com> From: Andy Bierman Date: Tue, 5 Jul 2016 09:57:42 -0700 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1142fff0fc477b0536e659e1 Archived-At: Cc: media-types@iana.org, Netconf Subject: Re: [Netconf] request review of media type application/yang-data+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 16:57:47 -0000 --001a1142fff0fc477b0536e659e1 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 1, 2016 at 1:31 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > removing all text except the fragment identifier issue.... > > > > According to RFC 7303, sec. 5, any usage of +xml requires implementation > of > > the XPointerFramework > > https://www.w3.org/TR/2003/REC-xptr-framework-20030325/ > > Actually, it says SHOULD: > > If [XPointerFramework] and [XPointerElement] are inappropriate for > some XML-based media type, it SHOULD NOT follow the naming convention > '+xml'. > > > RESTCONF "fragments" are sub-trees within the YANG data structures. > > These are accessed by the request URI path and the "fields" query > parameter. > > XPointer is rather complex and completely redundant for RESTCONF. > > I'm not sure the "element()" scheme is complex to implement. The > "fields" query parameter probably takes more effort to implement. > > Note though that the "fields" query parameter is more expressive than > the "element()" scheme, and it works with other encodings than XML. > *if* we were to use XPointer instead of "fields", what would we do for > JSON? > IMO it would be a bad idea to have media-specific filtering. YANG provides an abstraction of datastore contents which we want to be independent of the various query response representations found in protocol messages. We are filtering on the datastore contents, not on the XML representation of individual query responses. > > So do we have to add text that a RESTCONF server MUST implement the > > "element" > > scheme? > > If this indeed is to be interpreted as a requirement, I'd rather not > use the "+xml" name. > > Are there any objections to dropping the +xml? What about dropping +json as well? http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml This page implies our "fields" parameter MUST NOT overlap with XPointer. > /martin > Andy --001a1142fff0fc477b0536e659e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 1, 2016 at 1:31 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> removing all text except the fragment identifier issue....
>
> According to RFC 7303, sec. 5, any usage of +xml requires implementati= on of
> the XPointerFramework
> https://www.w3.org/TR/2003/REC-xptr-fram= ework-20030325/

Actually, it says SHOULD:

=C2=A0 =C2=A0If [XPointerFramework] and [XPointerElement] are inappropriate= for
=C2=A0 =C2=A0some XML-based media type, it SHOULD NOT follow the naming con= vention
=C2=A0 =C2=A0'+xml'.

> RESTCONF "fragments" are sub-trees within the YANG data stru= ctures.
> These are accessed by the request URI path and the "fields" = query parameter.
> XPointer is rather complex and completely redundant for RESTCONF.

I'm not sure the "element()" scheme is complex to implement.= =C2=A0 The
"fields" query parameter probably takes more effort to implement.=

Note though that the "fields" query parameter is more expressive = than
the "element()" scheme, and it works with other encodings than XM= L.
*if* we were to use XPointer instead of "fields", what would we d= o for
JSON?


IMO it would be a = bad idea to have media-specific filtering.
YANG provides an abstr= action of datastore contents which we want to be independent
of t= he various query response representations found in protocol messages.
=

We are filtering on the datastore contents, not on the = XML representation
of individual query responses.

<= /div>


> So do we have to add text that a RESTCONF server MUST implement the > "element"
> scheme?

If this indeed is to be interpreted as a requirement, I'd rather not use the "+xml" name.



Are there any objections to dropping the +x= ml?

What about dropping +json as well?
<= br>

This page implies our "fields" paramete= r MUST NOT overlap with XPointer.



/martin


<= /div>
Andy

--001a1142fff0fc477b0536e659e1-- From nobody Tue Jul 5 10:17:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEA712D66D for ; Tue, 5 Jul 2016 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHCcs3Wn22QL for ; Tue, 5 Jul 2016 10:17:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F1712D1AE for ; Tue, 5 Jul 2016 10:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5772; q=dns/txt; s=iport; t=1467739025; x=1468948625; h=from:to:subject:date:message-id:mime-version; bh=nKa+Z1v03WEeSx7r/oqhBpvYwAb4J1N6pF+VhDXFd4g=; b=ILrnQvlf9+90Oawxtyu7hacMaLSc74aKpcqMvh1jkxK2ZzEvnb4owIJ/ EpJuaf9nS7p9ag8j/QLeU551vCTcmOJqxMdQm00HtxeoOF83VP0i6nr9j 4BrMYnuO2mEdezulgMtH+ZDjJdcRgC7f0b4UJPz55LGkbyiu1PTtTx95A I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AgDj6ntX/40NJK1cgnBOVoECtD+FA?= =?us-ascii?q?YF3h044FAEBAQEBAQFlHAuEUy1eAYEAJgEEG4gom2yfPwEBAQEGAQEBAQEBIYY?= =?us-ascii?q?njmgFiBOHI4ldAYEwjQ+PMZAJAR42g3CIQ38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,580,1459814400"; d="scan'208,217";a="122577694" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2016 17:17:04 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u65HH4kV024502 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jul 2016 17:17:04 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 12:17:03 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 12:17:03 -0500 From: "Steve Truong (struong)" To: "netconf@ietf.org" Thread-Topic: Comments on draft-ietf-netconf-restconf-14 - 7. Error Reporting Thread-Index: AdHW4QpV/KatMG8NR86vycmCNixZbQ== Date: Tue, 5 Jul 2016 17:17:03 +0000 Message-ID: <89b39e6d33364e8495a7b4267e324a1f@XCH-RCD-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.152.22] Content-Type: multipart/alternative; boundary="_000_89b39e6d33364e8495a7b4267e324a1fXCHRCD014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Comments on draft-ietf-netconf-restconf-14 - 7. Error Reporting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 17:17:07 -0000 --_000_89b39e6d33364e8495a7b4267e324a1fXCHRCD014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 7 (preferably) I'd like to see the mapping of the following HTTP= status code to the NETCONF : - 406 Not Acceptable - 412 Precondition Failed Can someone tell what they should be? Thanks, steve --_000_89b39e6d33364e8495a7b4267e324a1fXCHRCD014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 7 (preferably) I’d like to see the = mapping of the following HTTP status code to the NETCONF <error-tag>:

 

-     &= nbsp;    406 Not Acceptable

-     &= nbsp;    412 Precondition Failed

 

Can someone tell what they should be?

 

Thanks,

steve

--_000_89b39e6d33364e8495a7b4267e324a1fXCHRCD014ciscocom_-- From nobody Tue Jul 5 11:04:49 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0A12D533 for ; Tue, 5 Jul 2016 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6ACuJkEB-sv for ; Tue, 5 Jul 2016 11:04:45 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B38912D67E for ; Tue, 5 Jul 2016 11:04:45 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id m127so215284976vkb.3 for ; Tue, 05 Jul 2016 11:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kwxfBqyspwTEr40DFX1lxqoabZJgp9M5HWxUpwrf0jA=; b=ADRmykGLeViHLm+i2yWMN3X4gGjGUSzrKTbEbAWsb/LeCrDk7fdVWvAUXFPp42JWzD 3+eZswDFGhU17huCzAzlVXGKHLSDpW7NBDW86vlhNK7CPd92S7YODvJapfYIWZuyumvF x3UcNCgW0gwXfu5z67i3/Mq7z9bZtoSiFVzxDh+Unwye4YY8sCHxETdri0GyjWXyfkQh iNTPsjmbP8zZrqCTNSP1YruGOhgrpyJDkKQSbBNNbZLHCuOiixRTpNB29iFpsdBg1KLs WR/mXhCBZbqpwkLz1f6JZhffnSk7zUz9bF9ESfw7vA1nD5Knf6lKqyGJFGV95BlIbKJ8 nLjg== 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; bh=kwxfBqyspwTEr40DFX1lxqoabZJgp9M5HWxUpwrf0jA=; b=aYn6W3csWZeA0fgVhZ4UPmqdPE//W2xjQLQfagRhLrs0kuP+pGiA14eub5cBn6Gu5W ChKUMZuSutuEVme+VcW9qzL6bojoYZMq9wXuv9EMaGfa3/jKK87/24eUyNk1xpwBkw7n 2vdOgntA4Z+M6nbTNDqxe/mCH6gCwekvZ0oqzueB9b+f0GOZrvCvM9hDEOx1ofoZOfc8 NeiD1JJzDggWyXcjffJWUCnWE5yWfFtnhMu4kZEtR+/zuRHd1uN1TxGux6dUC9vyazMl s+bs+tImShC8zzal2EGgcsG9bgOoLfqFZU8RYvA6iqxDQ52wd+Y4/3RQX2JRG9c34edS Lqjw== X-Gm-Message-State: ALyK8tJwy59bSznGJ8NGG61WJwIO5z6umqENeshQEOSu9ohLLJKBnnFk07qUHw01C7oywyc6BvMfeAh1eZidSg== X-Received: by 10.176.69.243 with SMTP id u106mr7930014uau.135.1467741884240; Tue, 05 Jul 2016 11:04:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 5 Jul 2016 11:04:42 -0700 (PDT) In-Reply-To: <7a091e787f6a42ac9bb7d5225f042988@XCH-RTP-013.cisco.com> References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> <7a091e787f6a42ac9bb7d5225f042988@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Tue, 5 Jul 2016 11:04:42 -0700 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=94eb2c11be74a1ebd40536e74905 Archived-At: Cc: NETCONF Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:04:47 -0000 --94eb2c11be74a1ebd40536e74905 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 1, 2016 at 10:44 AM, Eric Voit (evoit) wrote: > Andy Bierman, July 01, 2016 12:13 AM > On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise wrote: > > > > - section 1 > > RESTCONF is based on HTTP1.1 [RFC7230] > > What about HTTP2 [RFC7540]? > > I've seen some discussions on the NETCONF mailing but I'm unclear if REST= CONF would work with HTTP2. > > A few words are necessary IMO. > > background: https://www.ietf.org/mail-archive/web/netconf/current/msg0857= 8.html > > I see in section 2.1 > > No other versions of HTTP are supported for use with RESTCONF. > > Do you mean: > > No other versions than HTTP 1.1 are supported for use with RESTCONF. > > So: > > HTTP2.0 MUST NOT be used with RESTCONF. > > If this is the case, some sort of justification is required. > > > > You have to say something about HTTP2 > > > > > > The WG needs to decide what to say, and what section needs to be updated. > > There is a lot of text that cites HTTP 1.1. > > > > I would prefer a small number of edits; MUST support HTTP 1.1; MAY suppor= t > HTTP/2 > > > > > > HTTP/2 needs to be allowed, even if no text examples are provided= . > > > > Is there any concern with sequencing of transactions here? Section 2.1 > says =E2=80=9CResponses MUST be sent in the same order that requests are > received.=E2=80=9D Different POST, PUT, PATCH Server responses might en= d up on > different HTTP/2 streams and still meet this requirement. We should > preclude this possibility in the text. > > > > Is it feasible to add requirement that all requests made from one HTTP/2 > stream must be returned within a single HTTP/2 stream? This would enabl= e > pipelining for an initiating application. It would also allow paralleli= sm > for RESTCONF Server initiated messages which can safely be multiplexed. > > > How about this text added to sec 2.1? HTTP/2 [RFC7540] MAY be used for RESTCONF. The server MUST respond using the same HTTP/2 stream that was used for the corresponding request. I think this also covers the GET for notifications. Eric > Andy --94eb2c11be74a1ebd40536e74905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 1, 2016 at 10:44 AM, Eric Voit (evoit) &l= t;evoit@cisco.com&= gt; wrote:

Andy Bierman, July 01, 2016 12:13 AM
On Wed, Jun 29, 2016 at 6:13 AM, Benoit Claise <bclaise@cisco.com> wrote:

=C2=A0

- section 1
RESTCONF is based on HTTP1.1 [RFC7230]
What about HTTP2 [RFC7540]? 
I've seen some discussions on the NETCONF mailing but I'm uncl=
ear if RESTCONF would work with HTTP2.
A few words are necessary IMO.
background: https://www.ietf.org/mail-archive/w=
eb/netconf/current/msg08578.html
I see in section 2.1
=C2=A0=C2=A0 No other versions of HTTP are supported for use with REST=
CONF.
Do you mean:
=C2=A0=C2=A0 No other versions than HTTP 1.1 are supported for use wit=
h RESTCONF.
So:
=C2=A0=C2=A0 HTTP2.0 MUST NOT be used with RESTCONF.

If this is the case, some sort of justification is required.=



=C2=A0

You have to say something about HTTP2<= /p>

=C2=A0

=C2=A0

The WG needs to decide what to say, and what section= needs to be updated.

There is a lot of text that cites HTTP 1.1.

=C2=A0

I would prefer a small number of edits; MUST support= HTTP 1.1; MAY support HTTP/2

=C2=A0

=C2=A0

<Eric>=C2=A0 HTTP/2 needs to be allowe= d, even if no text examples are provided.

=C2=A0

Is there any concern with sequencing of tran= sactions here?=C2=A0 Section 2.1 says =E2=80=9CResponses MUST be sent in th= e same order that requests are received.=E2=80=9D=C2=A0 =C2=A0Different POST, PUT, PATCH Server responses might end up on different HTTP/2 streams= and still meet this requirement.=C2=A0 We should preclude this possibility= in the text.

=C2=A0

Is it feasible to add requirement that all r= equests made from one HTTP/2 stream must be returned within a single HTTP/2= stream?=C2=A0 =C2=A0This would enable pipelining for an initiating application.=C2=A0=C2=A0 It would also allow parallelism= for RESTCONF Server initiated messages which can safely be multiplexed.=C2= =A0

=C2=A0

=


How about this text added to =C2=A0sec 2.1?

=C2=A0 =C2=A0 =C2=A0HTTP/2 [RFC7540] MAY be used for RESTCONF.
=C2=A0 =C2=A0 =C2=A0The server MUST respond using the same HTTP/2 str= eam
=C2=A0 =C2=A0 =C2=A0that was used for the corresponding reque= st.


I think this also covers = the GET for notifications.


Eric



Andy

--94eb2c11be74a1ebd40536e74905-- From nobody Tue Jul 5 11:33:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DD712B050 for ; Tue, 5 Jul 2016 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfiGRXfa60sa for ; Tue, 5 Jul 2016 11:33:49 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCD012D1ED for ; Tue, 5 Jul 2016 11:33:48 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id k68so189215035vkb.0 for ; Tue, 05 Jul 2016 11:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lUHRBf2uJ+tOULt+Z56UG9UjZpLrysmC4sGm85FRNaM=; b=TkqV9AOp/3yrOLs93mmoYgM1H7dv06iOpu69uXS5u8TpVLwq1IckC5W+w5x//YOpsy iSmj66lfv7R9kiONw/ILgMqoD2tTkMk3Zq0tr3QT29Vr2VuB7YANFlnN61Q0K7TzHjHo zCqxpcHjxlrifxLMhGlVq1XSwoi6jHFJAgcrbfLd/ygppV3I5KnmrtGdTuUp+tMj3ojq 6TsSIgeo5+iaDMB6zFvrxdY1yGMPD+s/n3/tg90eOhox9PrVP7+YqRUG2UREqRzBejga /XKuZTxYsRM3aWe4EK2McYtlH+FTmntm6LYHzElTjbHE9sgq1iUxO/H6Q/wh3P4/6KEx XrSA== 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; bh=lUHRBf2uJ+tOULt+Z56UG9UjZpLrysmC4sGm85FRNaM=; b=fVOVJUchanGqhgUEVg2Gk8PiTFtD09k7fx+oPYXw8nJcyF3vSFiqSGQawJLmgSanYO /NWXw9q8eA8n4LH/ihhncl6L3gCWuMN/fE83pDRQCdE/bqzQXyb1EytU0E8HVub6O84B ioJVSMCUMBwirHPHi1RMv1zbuNOB8khMOoJ4hCtBf8I/ghBnfffh56bmbIlTax4/cLgk BQf42HVjL3c1pCqRIL36QpAA+HpQJkgSLdsMosf2OSCA37uh3DrMW7EnSFIbAFci/j6G ABVie6p1QV2nLXnT2Y7PpeDsMyPR9s9xmOzy5IHA9Pxr8CVBOMB5NsxBZ3vB4QlLi7It HHsQ== X-Gm-Message-State: ALyK8tIwKWESSKjSXPeZ346wJ8bQDdJhVmKE9WDDtdxH9ky/1kEfZBIM3BVVBmFZ5wAB3ydEKdnBXvoBDkvYag== X-Received: by 10.31.70.193 with SMTP id t184mr8348600vka.123.1467743628081; Tue, 05 Jul 2016 11:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 5 Jul 2016 11:33:47 -0700 (PDT) In-Reply-To: <89b39e6d33364e8495a7b4267e324a1f@XCH-RCD-014.cisco.com> References: <89b39e6d33364e8495a7b4267e324a1f@XCH-RCD-014.cisco.com> From: Andy Bierman Date: Tue, 5 Jul 2016 11:33:47 -0700 Message-ID: To: "Steve Truong (struong)" Content-Type: multipart/alternative; boundary=001a1148907692cf9f0536e7b16d Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-14 - 7. Error Reporting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:33:51 -0000 --001a1148907692cf9f0536e7b16d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 5, 2016 at 10:17 AM, Steve Truong (struong) wrote: > In section 7 (preferably) I=E2=80=99d like to see the mapping of the foll= owing > HTTP status code to the NETCONF : > > > > - 406 Not Acceptable > we are sending invalid-value > - 412 Precondition Failed > we are sending operation-failed > > > Can someone tell what they should be? > Does anybody want to suggest different error-tags? > > > Thanks, > > steve > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1148907692cf9f0536e7b16d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 5, 2016 at 10:17 AM, Steve Truong (struong) <struong@cisco= .com> wrote:

In section 7 (preferably) I=E2=80=99d like to see th= e mapping of the following HTTP status code to the NETCONF <error-tag>:

=C2=A0

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 406 Not Acceptable

we are sending invalid-value

=C2=A0

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 412 Precondition Failed



we are sending operation-failed
=
=C2=A0

=C2=A0

Can someone tell what they should be?



Does anybody want to sugge= st different error-tags?

=C2=A0
<= p class=3D"MsoNormal">

=C2=A0

Thanks,

steve


Andy
=C2=A0

<= /u>


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


--001a1148907692cf9f0536e7b16d-- From nobody Tue Jul 5 21:14:08 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50D12D603 for ; Tue, 5 Jul 2016 21:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0GVWybG0JmO for ; Tue, 5 Jul 2016 21:14:05 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E4312D50E for ; Tue, 5 Jul 2016 21:14:05 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id r2so256652645oih.2 for ; Tue, 05 Jul 2016 21:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=tEcGVXwJgrrDDm+5QX7QjmM1imS3aHhWUOi/sP7msbY=; b=LfA7QYlNq7Jd/mGmnr04yw3ryGRbKndE88w8/0+bqRB73SpOF9LtDZYC8fp0pN5XCs dUpqu7v9pTqd1XVOaAsQGYobGonG3gcB7ZX+MWVfXxcDODtEN7a6LPWq1J0JCFKOVEt1 89PY0iTRis/OIWR2t9kj4QXhgQlo/5iPWvjhkDts5Q5MYz7Ui53nIJ7sCE9AndrJ3fYU +6xp36MNrYl2uIzvpdZRiAlz7Om6WUnXRmkbyY00T0kdtYvfdHvo1KC4yGL0LpPl8zT4 JCm2+y6rZCec/2dpMWgVM9DFXTTSjV4bWIOUag2dbxJoIpxSvTJah55UFDlxVP+r2QJ4 mtXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=tEcGVXwJgrrDDm+5QX7QjmM1imS3aHhWUOi/sP7msbY=; b=f++uIz0Axwu/T7Q6+yrSx0q53UPvMAUEn5Cua/A0Yc72767N5AanuNgXQjACGtIQ+3 U1Xjjxu/+24ovfnYB9xk+6IhAWealOgnTMRBdRmog35ngdT8Fu0c4At00eTELSVclTg9 HUQPAlVVB7a3Tcx1/p+K1ivZQOxnw5EZhwuEqugqnajG2NBJCVODxrUDOhrruA6uZ+BH MZCwwhN8MnyUb8chCnk9v4d9G4TijnuR5Sk7ZvpJOdfUeFvhcd5hsJTmDlUfQUMR/i0t nGj5x/cEo05vNNu5SBwPKQkY7scg4kZevCUpV+fY6/oNgj2vqqd2vN7g/lKzTw40XEYb U9eg== X-Gm-Message-State: ALyK8tJKRWILTCVdz1dQOTdGtziOMsnqrJ3q+LGux12BMfFKP+aFTvLHVkCNkawhyQsEDA== X-Received: by 10.202.182.66 with SMTP id g63mr12198773oif.69.1467778444358; Tue, 05 Jul 2016 21:14:04 -0700 (PDT) Received: from ?IPv6:2602:306:cf77:df90:f8bf:7cff:183c:e5bc? ([2602:306:cf77:df90:f8bf:7cff:183c:e5bc]) by smtp.gmail.com with ESMTPSA id 65sm9002114otp.19.2016.07.05.21.14.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jul 2016 21:14:03 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 5 Jul 2016 21:14:02 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Agenda Requests X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 04:14:06 -0000 It is that time again where we ask if you want to present in the NETCONF = session at IETF 96. Please indicate Topic: Length: Presenter: in your request for the slot.=20 All this assumes that you have published/updated a draft on the mailing = list and have garnered some discussion around it. If not, there is still = time to do that before the meeting. Cheers. Mahesh & Mehmet From nobody Wed Jul 6 10:24:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91612D094 for ; Wed, 6 Jul 2016 10:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PVOa4DUutIx for ; Wed, 6 Jul 2016 10:24:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE3F12D147 for ; Wed, 6 Jul 2016 10:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20376; q=dns/txt; s=iport; t=1467825861; x=1469035461; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+YnzbL39advIZjnTEz843b/sCYvHFL/9oIJiL8IOdto=; b=SV7VGYkST4EKFwa6C0Gka0OB4lb8SppTgMUesTMXKXy6sks0Tn+udvTC sSobf9RmXU5lVX3teSLJrjHQDmQzXq7paflKdcJK9AGE4Jyggy3EKhR5n jHMwrcw/FN5EhvrmTKVm3aKKKgf3nwdDLpsgdSDXzp6WqJKcWcDSCEE0L c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAgCpPX1X/5RdJa1dgnBOVnwGtBSFA?= =?us-ascii?q?YF3IoUsSgIcgQ44FAEBAQEBAQFlJ4RMAQEFIwpBCxACAQgVKgMCAgIwFBECBA4?= =?us-ascii?q?FCIgoDqxSj2ABAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhE2EIwEBBSQJH4JLg?= =?us-ascii?q?loFk1mFOgGJAoU9jzGQCQEeNoNwbgGHPDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,320,1464652800"; d="scan'208,217";a="292900010" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 17:24:20 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u66HOKd0022444 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 17:24:20 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 13:24:19 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 13:24:19 -0400 From: "Eric Voit (evoit)" To: Andy Bierman Thread-Topic: [Netconf] AD review of draft-ietf-netconf-restconf-13 Thread-Index: AQHR0079Bb97qyvcr0SoS3VG6WaIn6ADz+rAgAab7gCAATDmwA== Date: Wed, 6 Jul 2016 17:24:18 +0000 Message-ID: References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> <4e94400e-62fa-c472-9ea1-c606fcbde026@cisco.com> <7a091e787f6a42ac9bb7d5225f042988@XCH-RTP-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.248.5] Content-Type: multipart/alternative; boundary="_000_eaeb465ad57a45fb8ca3808343a33b01XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETCONF Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 17:24:23 -0000 --_000_eaeb465ad57a45fb8ca3808343a33b01XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQW5keSBCaWVybWFuLCBKdWx5IDA1LCAyMDE2IDI6MDUgUE0NCg0KT24gRnJpLCBKdWwg MSwgMjAxNiBhdCAxMDo0NCBBTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxt YWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3JvdGU6DQpBbmR5IEJpZXJtYW4sIEp1bHkgMDEsIDIw MTYgMTI6MTMgQU0NCk9uIFdlZCwgSnVuIDI5LCAyMDE2IGF0IDY6MTMgQU0sIEJlbm9pdCBDbGFp c2UgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+IHdyb3RlOg0K DQoNCi0gc2VjdGlvbiAxDQoNClJFU1RDT05GIGlzIGJhc2VkIG9uIEhUVFAxLjEgW1JGQzcyMzBd DQoNCldoYXQgYWJvdXQgSFRUUDIgW1JGQzc1NDBdPw0KDQpJJ3ZlIHNlZW4gc29tZSBkaXNjdXNz aW9ucyBvbiB0aGUgTkVUQ09ORiBtYWlsaW5nIGJ1dCBJJ20gdW5jbGVhciBpZiBSRVNUQ09ORiB3 b3VsZCB3b3JrIHdpdGggSFRUUDIuDQoNCkEgZmV3IHdvcmRzIGFyZSBuZWNlc3NhcnkgSU1PLg0K DQpiYWNrZ3JvdW5kOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNv bmYvY3VycmVudC9tc2cwODU3OC5odG1sDQoNCkkgc2VlIGluIHNlY3Rpb24gMi4xDQoNCiAgIE5v IG90aGVyIHZlcnNpb25zIG9mIEhUVFAgYXJlIHN1cHBvcnRlZCBmb3IgdXNlIHdpdGggUkVTVENP TkYuDQoNCkRvIHlvdSBtZWFuOg0KDQogICBObyBvdGhlciB2ZXJzaW9ucyB0aGFuIEhUVFAgMS4x IGFyZSBzdXBwb3J0ZWQgZm9yIHVzZSB3aXRoIFJFU1RDT05GLg0KDQpTbzoNCg0KICAgSFRUUDIu MCBNVVNUIE5PVCBiZSB1c2VkIHdpdGggUkVTVENPTkYuDQoNCklmIHRoaXMgaXMgdGhlIGNhc2Us IHNvbWUgc29ydCBvZiBqdXN0aWZpY2F0aW9uIGlzIHJlcXVpcmVkLg0KDQoNCllvdSBoYXZlIHRv IHNheSBzb21ldGhpbmcgYWJvdXQgSFRUUDINCg0KDQpUaGUgV0cgbmVlZHMgdG8gZGVjaWRlIHdo YXQgdG8gc2F5LCBhbmQgd2hhdCBzZWN0aW9uIG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQpUaGVyZSBp cyBhIGxvdCBvZiB0ZXh0IHRoYXQgY2l0ZXMgSFRUUCAxLjEuDQoNCkkgd291bGQgcHJlZmVyIGEg c21hbGwgbnVtYmVyIG9mIGVkaXRzOyBNVVNUIHN1cHBvcnQgSFRUUCAxLjE7IE1BWSBzdXBwb3J0 IEhUVFAvMg0KDQoNCjxFcmljPiAgSFRUUC8yIG5lZWRzIHRvIGJlIGFsbG93ZWQsIGV2ZW4gaWYg bm8gdGV4dCBleGFtcGxlcyBhcmUgcHJvdmlkZWQuDQoNCklzIHRoZXJlIGFueSBjb25jZXJuIHdp dGggc2VxdWVuY2luZyBvZiB0cmFuc2FjdGlvbnMgaGVyZT8gIFNlY3Rpb24gMi4xIHNheXMg4oCc UmVzcG9uc2VzIE1VU1QgYmUgc2VudCBpbiB0aGUgc2FtZSBvcmRlciB0aGF0IHJlcXVlc3RzIGFy ZSByZWNlaXZlZC7igJ0gICBEaWZmZXJlbnQgUE9TVCwgUFVULCBQQVRDSCBTZXJ2ZXIgcmVzcG9u c2VzIG1pZ2h0IGVuZCB1cCBvbiBkaWZmZXJlbnQgSFRUUC8yIHN0cmVhbXMgYW5kIHN0aWxsIG1l ZXQgdGhpcyByZXF1aXJlbWVudC4gIFdlIHNob3VsZCBwcmVjbHVkZSB0aGlzIHBvc3NpYmlsaXR5 IGluIHRoZSB0ZXh0Lg0KDQpJcyBpdCBmZWFzaWJsZSB0byBhZGQgcmVxdWlyZW1lbnQgdGhhdCBh bGwgcmVxdWVzdHMgbWFkZSBmcm9tIG9uZSBIVFRQLzIgc3RyZWFtIG11c3QgYmUgcmV0dXJuZWQg d2l0aGluIGEgc2luZ2xlIEhUVFAvMiBzdHJlYW0/ICAgVGhpcyB3b3VsZCBlbmFibGUgcGlwZWxp bmluZyBmb3IgYW4gaW5pdGlhdGluZyBhcHBsaWNhdGlvbi4gICBJdCB3b3VsZCBhbHNvIGFsbG93 IHBhcmFsbGVsaXNtIGZvciBSRVNUQ09ORiBTZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIHdoaWNo IGNhbiBzYWZlbHkgYmUgbXVsdGlwbGV4ZWQuDQoNCg0KDQpIb3cgYWJvdXQgdGhpcyB0ZXh0IGFk ZGVkIHRvICBzZWMgMi4xPw0KDQogICAgIEhUVFAvMiBbUkZDNzU0MF0gTUFZIGJlIHVzZWQgZm9y IFJFU1RDT05GLg0KICAgICBUaGUgc2VydmVyIE1VU1QgcmVzcG9uZCB1c2luZyB0aGUgc2FtZSBI VFRQLzIgc3RyZWFtDQogICAgIHRoYXQgd2FzIHVzZWQgZm9yIHRoZSBjb3JyZXNwb25kaW5nIHJl cXVlc3QuDQoNCg0KSSB0aGluayB0aGlzIGFsc28gY292ZXJzIHRoZSBHRVQgZm9yIG5vdGlmaWNh dGlvbnMuDQoNCg0KPEVyaWM+ICBJIHRoaW5rIHRoaXMgYWxsb3dzIHRoZSBtYWluIG9iamVjdGl2 ZSBvZiBhbGxvd2luZyBwYXJhbGxlbGlzbSBhcyBhIGNsaWVudCBjYW4gdXNlIGRpZmZlcmVudCBz dHJlYW1zIGZvciB0aG9zZSByZXF1ZXN0cyB3aGljaCBjYW4gc2FmZWx5IGJlIGRvbmUgaW4gcGFy YWxsZWwuICAoVGhpcyBzaG91bGRu4oCZdCBhZGQgYW55dGhpbmcgc3VycHJpc2luZyBhcyBjb25u ZWN0aW9ucyB0byBhIFJFU1RDT05GIHNlcnZlciBjYW4gY29tZSBpbiBmcm9tIG11bHRpcGxlIGNs aWVudHMuKQ0KDQpJIHRoaW5rIHRoZSB3b3JkaW5nIGNvdWxkIGJlIHR3ZWFrZWQgYSBsaXR0bGUg Yml0IGFzIGhlcmUgYXJlIGJlbmVmaXRzIGZyb20gdGhlIEhUVFAvMiBwcm90b2NvbCBpZiB1c2lu ZyB0aGUgc2FtZSBzdGVhbS1pZCBmb3IgcmVzcG9uc2VzIGlzIG5vdCBtYW5kYXRlZC4NCg0KTXkg c3VnZ2VzdGVkIHRleHQgd291bGQgYmU6DQoNCkhUVFAvMiBbUkZDNzU0MF0gTUFZIGJlIHVzZWQg Zm9yIFJFU1RDT05GLiAgVGhlIHNlcnZlciBNVVNUIHJlc3BvbmQgdXNpbmcgc2luZ2xlIEhUVFAv MiBzdHJlYW0gZm9yIGFsbCBjbGllbnQgcmVxdWVzdHMgZnJvbSBhIHN0cmVhbS4gIFRoZSBzZXJ2 ZXIgTUFZIHJlc3BvbmQgdXNpbmcgc2FtZSBIVFRQLzIgc3RyZWFtIHRoYXQgd2FzIHVzZWQgZm9y IHRoZSBjb3JyZXNwb25kaW5nIHJlcXVlc3QuDQoNCkVyaWMNCkVyaWMNCg0KDQpBbmR5DQoNCg== --_000_eaeb465ad57a45fb8ca3808343a33b01XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5keSBC aWVybWFuLCBKdWx5IDA1LCAyMDE2IDI6MDUgUE08YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdWwgMSwgMjAxNiBh dCAxMDo0NCBBTSwgRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkFuZHkgQmllcm1hbiwgSnVseSAwMSwgMjAxNiAxMjoxMyBBTTxicj4NCjwv c3Bhbj5PbiBXZWQsIEp1biAyOSwgMjAxNiBhdCA2OjEzIEFNLCBCZW5vaXQgQ2xhaXNlICZsdDs8 YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2xhaXNl QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlPi0gc2VjdGlvbiAxPG86cD48L286cD48L3By ZT4NCjxwcmU+UkVTVENPTkYgaXMgYmFzZWQgb24gSFRUUDEuMSBbUkZDNzIzMF08bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5XaGF0IGFib3V0IEhUVFAyIFtSRkM3NTQwXT8gPG86cD48L286cD48L3By ZT4NCjxwcmU+SSd2ZSBzZWVuIHNvbWUgZGlzY3Vzc2lvbnMgb24gdGhlIE5FVENPTkYgbWFpbGlu ZyBidXQgSSdtIHVuY2xlYXIgaWYgUkVTVENPTkYgd291bGQgd29yayB3aXRoIEhUVFAyLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkEgZmV3IHdvcmRzIGFyZSBuZWNlc3NhcnkgSU1PLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPmJhY2tncm91bmQ6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzA4NTc4Lmh0bWwiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3Vy cmVudC9tc2cwODU3OC5odG1sPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgc2VlIGluIHNl Y3Rpb24gMi4xPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IE5vIG90aGVyIHZl cnNpb25zIG9mIEhUVFAgYXJlIHN1cHBvcnRlZCBmb3IgdXNlIHdpdGggUkVTVENPTkYuPG86cD48 L286cD48L3ByZT4NCjxwcmU+RG8geW91IG1lYW46PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IE5vIG90aGVyIHZlcnNpb25zIHRoYW4gSFRUUCAxLjEgYXJlIHN1cHBvcnRlZCBm b3IgdXNlIHdpdGggUkVTVENPTkYuPG86cD48L286cD48L3ByZT4NCjxwcmU+U286PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEhUVFAyLjAgTVVTVCBOT1QgYmUgdXNlZCB3aXRo IFJFU1RDT05GLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHRoaXMgaXMgdGhlIGNhc2UsIHNv bWUgc29ydCBvZiBqdXN0aWZpY2F0aW9uIGlzIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3UgaGF2 ZSB0byBzYXkgc29tZXRoaW5nIGFib3V0IEhUVFAyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFdH IG5lZWRzIHRvIGRlY2lkZSB3aGF0IHRvIHNheSwgYW5kIHdoYXQgc2VjdGlvbiBuZWVkcyB0byBi ZSB1cGRhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGVyZSBpcyBhIGxvdCBvZiB0ZXh0IHRoYXQgY2l0ZXMgSFRUUCAxLjEuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdv dWxkIHByZWZlciBhIHNtYWxsIG51bWJlciBvZiBlZGl0czsgTVVTVCBzdXBwb3J0IEhUVFAgMS4x OyBNQVkgc3VwcG9ydCBIVFRQLzI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsmbmJzcDsgSFRUUC8y IG5lZWRzIHRvIGJlIGFsbG93ZWQsIGV2ZW4gaWYgbm8gdGV4dCBleGFtcGxlcyBhcmUgcHJvdmlk ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUgYW55IGNvbmNlcm4gd2l0aCBzZXF1ZW5jaW5nIG9m IHRyYW5zYWN0aW9ucyBoZXJlPyZuYnNwOyBTZWN0aW9uIDIuMSBzYXlzIOKAnFJlc3BvbnNlcyBN VVNUIGJlIHNlbnQNCiBpbiB0aGUgc2FtZSBvcmRlciB0aGF0IHJlcXVlc3RzIGFyZSByZWNlaXZl ZC7igJ0mbmJzcDsgJm5ic3A7RGlmZmVyZW50IFBPU1QsIFBVVCwgUEFUQ0ggU2VydmVyIHJlc3Bv bnNlcyBtaWdodCBlbmQgdXAgb24gZGlmZmVyZW50IEhUVFAvMiBzdHJlYW1zIGFuZCBzdGlsbCBt ZWV0IHRoaXMgcmVxdWlyZW1lbnQuJm5ic3A7IFdlIHNob3VsZCBwcmVjbHVkZSB0aGlzIHBvc3Np YmlsaXR5IGluIHRoZSB0ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIGl0IGZlYXNpYmxlIHRvIGFkZCBy ZXF1aXJlbWVudCB0aGF0IGFsbCByZXF1ZXN0cyBtYWRlIGZyb20gb25lIEhUVFAvMiBzdHJlYW0g bXVzdCBiZSByZXR1cm5lZA0KIHdpdGhpbiBhIHNpbmdsZSBIVFRQLzIgc3RyZWFtPyZuYnNwOyAm bmJzcDtUaGlzIHdvdWxkIGVuYWJsZSBwaXBlbGluaW5nIGZvciBhbiBpbml0aWF0aW5nIGFwcGxp Y2F0aW9uLiZuYnNwOyZuYnNwOyBJdCB3b3VsZCBhbHNvIGFsbG93IHBhcmFsbGVsaXNtIGZvciBS RVNUQ09ORiBTZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIHdoaWNoIGNhbiBzYWZlbHkgYmUgbXVs dGlwbGV4ZWQuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgdGhpcyB0ZXh0IGFkZGVk IHRvICZuYnNwO3NlYyAyLjE/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO0hUVFAvMiBbUkZDNzU0 MF0gTUFZIGJlIHVzZWQgZm9yIFJFU1RDT05GLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc2VydmVyIE1V U1QgcmVzcG9uZCB1c2luZyB0aGUgc2FtZSBIVFRQLzIgc3RyZWFtPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO3Ro YXQgd2FzIHVzZWQgZm9yIHRoZSBjb3JyZXNwb25kaW5nIHJlcXVlc3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IHRoaXMgYWxzbyBjb3ZlcnMgdGhlIEdFVCBmb3Igbm90aWZpY2F0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7RXJp YyZndDsmbmJzcDsgSSB0aGluayB0aGlzIGFsbG93cyB0aGUgbWFpbiBvYmplY3RpdmUgb2YgYWxs b3dpbmcgcGFyYWxsZWxpc20gYXMgYSBjbGllbnQgY2FuIHVzZSBkaWZmZXJlbnQgc3RyZWFtcyBm b3IgdGhvc2UgcmVxdWVzdHMgd2hpY2ggY2FuIHNhZmVseSBiZSBkb25lIGluDQogcGFyYWxsZWwu Jm5ic3A7IChUaGlzIHNob3VsZG7igJl0IGFkZCBhbnl0aGluZyBzdXJwcmlzaW5nIGFzIGNvbm5l Y3Rpb25zIHRvIGEgUkVTVENPTkYgc2VydmVyIGNhbiBjb21lIGluIGZyb20gbXVsdGlwbGUgY2xp ZW50cy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSB3b3JkaW5nIGNvdWxkIGJlIHR3ZWFrZWQgYSBs aXR0bGUgYml0IGFzIGhlcmUgYXJlIGJlbmVmaXRzIGZyb20gdGhlIEhUVFAvMiBwcm90b2NvbCBp ZiB1c2luZyB0aGUgc2FtZSBzdGVhbS1pZCBmb3IgcmVzcG9uc2VzIGlzIG5vdCBtYW5kYXRlZC4g Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NeSBzdWdnZXN0ZWQgdGV4dCB3b3VsZCBiZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzNzYwOTI7bXNvLXN0eWxlLXRleHRmaWxs LWZpbGwtY29sb3I6IzM3NjA5Mjttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUi PkhUVFAvMiBbUkZDNzU0MF0gTUFZIGJlIHVzZWQgZm9yIFJFU1RDT05GLiAmbmJzcDtUaGUgc2Vy dmVyIE1VU1QgcmVzcG9uZCB1c2luZyBzaW5nbGUgSFRUUC8yIHN0cmVhbSBmb3IgYWxsIGNsaWVu dCByZXF1ZXN0cyBmcm9tIGEgc3RyZWFtLiZuYnNwOw0KIFRoZSBzZXJ2ZXIgTUFZIHJlc3BvbmQg dXNpbmcgc2FtZSBIVFRQLzIgc3RyZWFtIHRoYXQgd2FzIHVzZWQgZm9yIHRoZSBjb3JyZXNwb25k aW5nIHJlcXVlc3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXJpYzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_eaeb465ad57a45fb8ca3808343a33b01XCHRTP013ciscocom_-- From nobody Wed Jul 6 11:17:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D0812B059 for ; Wed, 6 Jul 2016 11:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfTQPEPi6ZYv for ; Wed, 6 Jul 2016 11:17:01 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA39012B04D for ; Wed, 6 Jul 2016 11:17:01 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-02v.sys.comcast.net with SMTP id KrNXbFEVqQRyhKrNcbeiUT; Wed, 06 Jul 2016 18:17:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467829020; bh=UJE8+W5xEZqcDCcgB0e5U07KsNxMSTwaDK9ApNdYK7A=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=j8KwIWm3+P1Bu1Pl5F9D3cun7bW4xv87aLOAuHIzPwj+jVxa+HOSPUNzNsA4RQdTZ 9S4YYY8GlrkkzIryYGq/Qlwvm/+7Hf5C6TxKOH44kqLcNLpAEOtf5wQ96V2H5xkedv lpa0I/C99qyIHKSzi17cwDg4hNeVFXjhnC6ryKuyOJu0H50vWy49cSqUgZmxdBSvHb x1SaNJH9U0BcfGL/172+ZyLwMPUMeiow8y7K22bRIMUrekPBb1VtDq0qkMO7TOuOKx r9RVWxrpfBIbgbp/F9uzRmCygXLUeOCv+DerFbMOstmpPagUn7cqQBYlGmml9lJ8sl JoNLQK4BM6E8A== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id KrNcbkfb2btHKKrNcbr2UE; Wed, 06 Jul 2016 18:17:00 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u66IGxsb014571; Wed, 6 Jul 2016 14:16:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u66IGxgY014567; Wed, 6 Jul 2016 14:16:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Andy Bierman In-Reply-To: (andy@yumaworks.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 06 Jul 2016 14:16:59 -0400 Message-ID: <87poqqaaxw.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLIWAGknnKPLQCQ4qxP358FOioO1eTdaDgpZ/JgKjQUc/ouVlfHAIhBN/BhVYEARS25Z93nKkK5fzHJW5EJLE1eOC/dIB3XkpSiFGELyahLTHFHRfk1K 1oMtH1NaUmASzBIGgfMX4gqOSvuKex0rDD3Cf76bON0/Wi9JV2br/aoOctTtTZGKmxqMXWhrJ/RB4kbDojbhtuN0Xj4N+YHOBi8= Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-14 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:17:03 -0000 Andy Bierman writes: > I have made all the edits except the 2nd 4.6 below Thanks! >> 4.6 >> >> Yang has been extended to allow non-unique key values. The result is >> that URLs may identify multiple data instances. This seems to be >> specified for GET (if JSON is used, GET can return multiple instances; >> if XML is used, a 400 response is given) and DELETE (only one instance >> (arbitrarily chosen) is deleted; this may be modified by query >> parameters). But PATCH does not seem to specify the behavior if >> multiple instances are selected. > > *** not sure what the previous comment is requested... perhaps sec. # is > wrong It turns out I was mistaken. Yang has been extended to allow non-unique values in leaf-lists, but only in non-configuration leaf-lists. (I was mistaken in thinking that non-unique key values are allowed in lists.) So we could have a module definition module example-1 { namespace "urn:oid:1.3.6.1.4.1.14490.4.20160706.1"; prefix "ex"; organization "Example, Inc."; leaf-list datum { type string; } } with a corresponding datastore alice bob bob The result is that URLs may identify multiple data instances. For instance, you can request GET /restconf/data/example-1:datum=bob HTTP/1.1 Host: example.com Accept: application/yang-data+json and get HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:02:40 GMT Server: example-server Content-Type: application/yang-data+json Cache-Control: no-cache ETag: "a74eefc993a2b" Last-Modified: Mon, 23 Apr 2012 11:02:14 GMT "example-1:datum" : "bob" "example-1:datum" : "bob" (If I am right that {...} should not appear there.) The specification for GET, section 4.3, handles this: if JSON is used, GET can return multiple instances; if XML is used, a 400 response is given. The question I had is what is the response if the URL for a PATCH operation identifies more than one data instance? The subtle point that I missed is that you can't edit non-configuration data, and configuration data does not allow non-unique values in a leaf-list. So any instance that you can direct a PATCH to will not have non-unique values, and the question cannot arise. Dale From nobody Wed Jul 6 11:41:38 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A72F12D595 for ; Wed, 6 Jul 2016 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkhaW0m6gGds for ; Wed, 6 Jul 2016 11:41:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6BC12D1E0 for ; Wed, 6 Jul 2016 11:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2982; q=dns/txt; s=iport; t=1467830495; x=1469040095; h=from:to:subject:date:message-id:mime-version; bh=xLX0dxnJ9Rcf2kEq8JwVBKZ/7uYs78fW4uFzGPIqbOI=; b=fQTBsXoZBFpWcPuo9WnD8zmBAJxxuzQlHKwABLu7M9dazyEUU2DyNVtN ywAe69OS/vCQrQoT4k84Jo+2HGRfZHrciTMCISFDu+7odp20HTKCscwPF SKBeE6IwkXIRG6B+RMtxWRiw0PPlkdMvNnKysYWmH2rvECpK4XEJNGfAg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgA7UH1X/4ENJK1cgnBOVoECtBSFA?= =?us-ascii?q?YF3IociOBQBAQEBAQEBZRwLhFMtXgEMdCYBBBuIKA6dB589AQEBAQEBBAEBAQE?= =?us-ascii?q?BAQEbBYYnjmgFmRMBgTCEWIg3jzGQCQEeNoNwiGF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,320,1464652800"; d="scan'208,217";a="125758910" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2016 18:41:34 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u66IfYV2004097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2016 18:41:34 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 13:41:34 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 13:41:34 -0500 From: "Steve Truong (struong)" To: "netconf@ietf.org" Thread-Topic: Comments on draft-ietf-netconf-yang-patch-09 Thread-Index: AdHXtgLS0SS/zE3EQuWHOU+D8uK8sw== Date: Wed, 6 Jul 2016 18:41:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.152.22] Content-Type: multipart/alternative; boundary="_000_a0910264b2e047c3bdcec931fe103abcXCHRCD014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Comments on draft-ietf-netconf-yang-patch-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:41:37 -0000 --_000_a0910264b2e047c3bdcec931fe103abcXCHRCD014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yang Patch operation can target a datastore resource. Can we add examples= of datastore patching where multiple YANG modules are involved (we need to= have at least 2 modules for the demonstration)? The module ietf-yang-patch doesn't seem to be compilable? Should it? Thanks, steve --_000_a0910264b2e047c3bdcec931fe103abcXCHRCD014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yang Patch operation can target a datastore resource= .   Can we add examples of datastore patching where multiple YANG= modules are involved (we need to have at least 2 modules for the demonstra= tion)?

 

The module ietf-yang-patch doesn’t seem to be compilable?  Shoul= d it?

 

Thanks,

steve

--_000_a0910264b2e047c3bdcec931fe103abcXCHRCD014ciscocom_-- From nobody Wed Jul 6 11:52:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8F12D50A for ; Wed, 6 Jul 2016 11:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TdiakHBY3fp for ; Wed, 6 Jul 2016 11:52:35 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924C612D595 for ; Wed, 6 Jul 2016 11:52:35 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id t66so32791152vka.1 for ; Wed, 06 Jul 2016 11:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sF/NLIrA4UeVHoUdY0elkI69RMn7vxPnz5Yz0P/p5NU=; b=xcXCFmTMcAVPj8kFws5WrWwA1am0y/Oeo8PTmLSPXYL2FsKgZ8DboCADOs9qeKE3GH Ou23umTy4QXYwHy5lB+07ehS9/5svNvuq1QcqPien+CvY9T2YxlpTDJxc+iAZLCZJNRZ OmHBlBUbBuR9Pe8qJ8dGNUsS1AYrb8zXM7qiMgCiXc6PexLIMLhoWnmbstagvq93EWSO v5Fo4pERjgbCm+Ig7hqfXTDW6hT+EVDpEJND1ML3lz33SbS8IB9/AogfFr+QIY2KwIku UbWywuf9rahMrVBCxdOWIEjW8amQL3O4MnHC1jjMoZy7y/F9ahj8izmwEw3azOhsgGg7 ETEQ== 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; bh=sF/NLIrA4UeVHoUdY0elkI69RMn7vxPnz5Yz0P/p5NU=; b=hhPqDU+KfohjgLP4DDSikJNAWU5Q0AmPe6G6zZWh58gdStkoDXT1Y7pYqmmiAW7hyy 7cfNhfpmHVwS3EMaOPveRILSG8NQbWvSXsscz30h6y4uJtgty6z+Nk6fEyAgCEyghdWo EpnOIqw4mYzgITnm32R0wgwqXt3EyGZETm+Z/4SVCfZaNkMWMl9/2PCTkQX6csdVOHun vT4an0CgHXPVaD/bMAby+tiSYBjrcpjkl5AynYlmUkYL/h/KxZe33Jj83FLRIZV8k5nQ 2kAW4BXFFAyeTWbp67cQcFtd5Yfbi97LIDLLxvIDsnAoZ8NNXeZoQGg7yJHbaty27tU+ 11LA== X-Gm-Message-State: ALyK8tKDd90CawdOlBdhs4QSgBVIDmW0cS/IEp1VmP5A/dY8E8PYUYQoCksJcdDPv70+ocsKPUKDhrvAF06B0Q== X-Received: by 10.31.4.4 with SMTP id 4mr11066862vke.121.1467831154671; Wed, 06 Jul 2016 11:52:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 6 Jul 2016 11:52:33 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 6 Jul 2016 11:52:33 -0700 Message-ID: To: "Steve Truong (struong)" Content-Type: multipart/alternative; boundary=001a114298c890a1a30536fc1245 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-patch-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:52:37 -0000 --001a114298c890a1a30536fc1245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2016 at 11:41 AM, Steve Truong (struong) wrote: > Yang Patch operation can target a datastore resource. Can we add > examples of datastore patching where multiple YANG modules are involved (= we > need to have at least 2 modules for the demonstration)? > > > > The module ietf-yang-patch > > doesn=E2=80=99t seem to be compilable? Should it? > > > Not sure why this seems complicated The "target" for edit1 is set to /foo-mod:X The "target" for edit2 is set to /bar-mod:X Thanks, > > steve > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a114298c890a1a30536fc1245 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 6, 2016 at 11:41 AM, Steve Truong (struong) <struong@cisco= .com> wrote:

Yang Patch operation can target a datastore resource= .=C2=A0=C2=A0 Can we add examples of datastore patching where multiple YANG= modules are involved (we need to have at least 2 modules for the demonstra= tion)?

=C2=A0

The module ietf-yang-patch doesn=E2=80=99t seem to be compilable?=C2=A0 Sho= uld it?

=C2=A0


<= /div>
Not sure why this seems complicated

The = "target" for edit1 is set to /foo-mod:X
The "targe= t" for edit2 is set to /bar-mod:X


Thanks,

steve


Andy
=C2=A0


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


--001a114298c890a1a30536fc1245-- From nobody Wed Jul 6 11:54:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E512D50D for ; Wed, 6 Jul 2016 11:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 hw1cHw2T0bjx for ; Wed, 6 Jul 2016 11:54:13 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD9012D1F0 for ; Wed, 6 Jul 2016 11:54:12 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3D751509B6; Wed, 6 Jul 2016 14:54:10 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: Date: Wed, 6 Jul 2016 11:53:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------49BC0C13FAE1326A50751AC5" Archived-At: Cc: Netconf Subject: Re: [Netconf] request review of media type application/yang-patch+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:54:15 -0000 This is a multi-part message in MIME format. --------------49BC0C13FAE1326A50751AC5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry I did not respond to this before. Looks good. Same comments as application/yang-data+xml. The template is copied and pasted below for mailing list reference. Sean On 6/28/2016 7:29 PM, Andy Bierman wrote: > Hi, > > Please review and provide feedback on the media type registration > for YANG Patch media type for the PATCH method. This is used by > the RESTCONF protocol. > > > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.1 > > > thanks, > Andy Type name: application Subtype name: yang-patch+xml Required parameters: none Optional parameters: none // RFC Ed.: replacedraft-ietf-netmod-rfc6020bis with // the actual RFC reference for YANG 1.1, and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [draft-ietf-netmod-rfc6020bis ]. In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilizes the YANG Patch data structure. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .xml Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON (One of COMMON, LIMITED USE, or OBSOLETE.) Restrictions on usage: n/a // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no --------------49BC0C13FAE1326A50751AC5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry I did not respond to this before.

Looks good. Same comments as application/yang-data+xml. The template is copied and pasted below for mailing list reference.

Sean

On 6/28/2016 7:29 PM, Andy Bierman wrote:
Hi,

Please review and provide feedback on the media type registration
for  YANG Patch media type for the PATCH method.  This is used by
the RESTCONF protocol.




thanks,
Andy

      Type name: application

      Subtype name: yang-patch+xml

      Required parameters: none

      Optional parameters: none

     // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
     // the actual RFC reference for YANG 1.1, and remove this note.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // and remove this note

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to
         XML Encoding Rules and Canonical Format for the specific
         YANG data node type defined in [draft-ietf-netmod-rfc6020bis].
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
     // section number for Security Considerations
     // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
     // RFC number, and remove this note.

      Security considerations: Security considerations related
         to the generation and consumption of RESTCONF messages
         are discussed in Section NN of [RFCXXXX].
         Additional security considerations are specific to the
         semantics of particular YANG data models. Each YANG module
         is expected to specify security considerations for the
         YANG data defined in that module.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Interoperability considerations: [RFCXXXX] specifies format of
         conforming messages and the interpretation thereof.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Published specification: RFC XXXX

      Applications that use this media type: Instance document
        data parsers used within a protocol or automation tool
        that utilizes the YANG Patch data structure.

      Fragment identifier considerations: The fragment field in the
         request URI has no defined purpose.

      Additional information:

        Deprecated alias names for this type: n/a
        Magic number(s): n/a
        File extension(s): .xml
        Macintosh file type code(s): "TEXT"

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Person & email address to contact for further information: See
         Authors' Addresses section of [RFCXXXX].

      Intended usage: COMMON

      (One of COMMON, LIMITED USE, or OBSOLETE.)

      Restrictions on usage: n/a

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Author: See Authors' Addresses section of [RFCXXXX].

      Change controller: Internet Engineering Task Force
         (mailto:iesg&ietf.org).

      Provisional registration? (standards tree only): no


--------------49BC0C13FAE1326A50751AC5-- From nobody Wed Jul 6 11:55:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75912D5D2 for ; Wed, 6 Jul 2016 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 ClHD3LWbC3db for ; Wed, 6 Jul 2016 11:55:12 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDADE12D607 for ; Wed, 6 Jul 2016 11:55:11 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A83E2509B5; Wed, 6 Jul 2016 14:55:10 -0400 (EDT) To: Andy Bierman , media-types@iana.org References: From: Sean Leonard Message-ID: <9137e33c-0b42-92f8-d55d-461617edc98a@seantek.com> Date: Wed, 6 Jul 2016 11:54:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F7B927A0AABDB91957280512" Archived-At: Cc: Netconf Subject: Re: [Netconf] request review of media type application/yang-patch+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:55:19 -0000 This is a multi-part message in MIME format. --------------F7B927A0AABDB91957280512 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry I did not respond to this before. Looks good. Same comments as application/yang-data+json. The template is copied and pasted below for mailing list reference. Sean On 6/28/2016 7:32 PM, Andy Bierman wrote: > Hi, > > Please review and provide feedback on the media type registration > for the YANG Patch media type for the PATCH method. This is used by > the RESTCONF protocol. > > > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-09#section-4.2.2 > Type name: application Subtype name: yang-patch+json Required parameters: none Optional parameters: none // RFC Ed.: replacedraft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replacedraft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [draft-ietf-netmod-yang-json ]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata ] In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilizes the YANG Patch data structure. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .json Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON (One of COMMON, LIMITED USE, or OBSOLETE.) Restrictions on usage: n/a // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no --------------F7B927A0AABDB91957280512 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry I did not respond to this before.

Looks good. Same comments as application/yang-data+json. The template is copied and pasted below for mailing list reference.

Sean

On 6/28/2016 7:32 PM, Andy Bierman wrote:
Hi,

Please review and provide feedback on the media type registration
for  the YANG Patch media type for the PATCH method.  This is used by
the RESTCONF protocol.




      Type name: application

      Subtype name: yang-patch+json

      Required parameters: none

      Optional parameters: none

     // RFC Ed.: replace draft-ietf-netmod-yang-json with
     // the actual RFC reference for JSON Encoding of YANG Data,
     //  and remove this note.

     // RFC Ed.: replace draft-ietf-netmod-yang-metadata with
     // the actual RFC reference for JSON Encoding of YANG Data,
     //  and remove this note.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // and remove this note

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to
         [draft-ietf-netmod-yang-json]. A data annotation is
         encoded according to [draft-ietf-netmod-yang-metadata]
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
     // section number for Security Considerations
     // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
     // RFC number, and remove this note.

      Security considerations: Security considerations related
         to the generation and consumption of RESTCONF messages
         are discussed in Section NN of [RFCXXXX].
         Additional security considerations are specific to the
         semantics of particular YANG data models. Each YANG module
         is expected to specify security considerations for the
         YANG data defined in that module.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Interoperability considerations: [RFCXXXX] specifies format of
         conforming messages and the interpretation thereof.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Published specification: RFC XXXX

      Applications that use this media type: Instance document
        data parsers used within a protocol or automation tool
        that utilizes the YANG Patch data structure.

      Fragment identifier considerations: The fragment field in the
         request URI has no defined purpose.

      Additional information:

        Deprecated alias names for this type: n/a
        Magic number(s): n/a
        File extension(s): .json
        Macintosh file type code(s): "TEXT"

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Person & email address to contact for further information: See
         Authors' Addresses section of [RFCXXXX].

      Intended usage: COMMON

      (One of COMMON, LIMITED USE, or OBSOLETE.)

      Restrictions on usage: n/a

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Author: See Authors' Addresses section of [RFCXXXX].

      Change controller: Internet Engineering Task Force
         (mailto:iesg&ietf.org).

      Provisional registration? (standards tree only): no


--------------F7B927A0AABDB91957280512-- From nobody Wed Jul 6 12:07:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0312D1E0 for ; Wed, 6 Jul 2016 12:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 80APb2n7GtQa for ; Wed, 6 Jul 2016 12:07:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19D312D1C2 for ; Wed, 6 Jul 2016 12:07:21 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 61E32509B6; Wed, 6 Jul 2016 15:07:20 -0400 (EDT) To: Andy Bierman , Martin Bjorklund References: <8f8db9b8-9917-4b26-25f6-ee0c19492bb9@seantek.com> <20160701.103113.301947010745595267.mbj@tail-f.com> From: Sean Leonard Message-ID: <25a8fc58-3f3e-72ee-6d8f-672b2ef53434@seantek.com> Date: Wed, 6 Jul 2016 12:06:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D84EB749CE4BBD121E27DEAB" Archived-At: Cc: media-types@iana.org, Netconf Subject: Re: [Netconf] [media-types] request review of media type application/yang-data+xml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 19:07:24 -0000 This is a multi-part message in MIME format. --------------D84EB749CE4BBD121E27DEAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 7/5/2016 9:57 AM, Andy Bierman wrote: > [...] > > IMO it would be a bad idea to have media-specific filtering. > YANG provides an abstraction of datastore contents which we want to be = > independent > of the various query response representations found in protocol message= s. > > We are filtering on the datastore contents, not on the XML representati= on > of individual query responses. > > > > > So do we have to add text that a RESTCONF server MUST implement t= he > > "element" > > scheme? > > If this indeed is to be interpreted as a requirement, I'd rather no= t > use the "+xml" name. > > > Are there any objections to dropping the +xml? > > What about dropping +json as well? > > http://www.iana.org/assignments/media-type-structured-suffix/media-type= -structured-suffix.xhtml > > This page implies our "fields" parameter MUST NOT overlap with XPointer= =2E I believe that +xml and +json should stay on. I have not seen the XPointer issue actually trip up a registration.=20 (However, the XPointer thing is kind of new, being in RFC 7303...) The=20 +xml is important because it signals to intermediaries that they can do=20 XML analysis. This strikes me as more important than the fragment stuff, = and would in any event be a justification to override the "SHOULD NOT=20 +xml" language. The media type reviewer should say something about this..= =2E I guess the bottom line for me is: are applications actually going to=20 use fragment identifiers--is there a commercial use case? Or is this=20 just pontificating about stuff that won't actually get implemented? If it's a real use case, do you want a uniform fragment identifier=20 syntax across data syntaxes, so that #foo refers to the same semantic=20 construct across +xml, +json, +cbor, etc.? And if so, why? (I get that=20 "YANG provides an abstraction of datastore contents which we want to be=20 independent of the various query response representations"; but, the=20 YANG processors are representation-aware...so the mere fact that=20 #xpointer-fragment-form and #json-fragment-form are different from each=20 other, does not strike me as a big deal. The YANG processors know about=20 XML vs. JSON so they have to do XML vs. JSON-specific things anyway.) Sean --------------D84EB749CE4BBD121E27DEAB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 7/5/2016 9:57 AM, Andy Bierman wrote:
[...]

IMO it would be a bad idea to have media-specific filtering.
YANG provides an abstraction of datastore contents which we want to be independent
of the various query response representations found in protocol messages.

We are filtering on the datastore contents, not on the XML representation
of individual query responses.



> So do we have to add text that a RESTCONF server MUST implement the
> "element"
> scheme?

If this indeed is to be interpreted as a requirement, I'd rather not
use the "+xml" name.


Are there any objections to dropping the +xml?

What about dropping +json as well?


This page implies our "fields" parameter MUST NOT overlap with XPointer.

I believe that +xml and +json should stay on.

I have not seen the XPointer issue actually trip up a registration. (However, the XPointer thing is kind of new, being in RFC 7303...) The +xml is important because it signals to intermediaries that they can do XML analysis. This strikes me as more important than the fragment stuff, and would in any event be a justification to override the "SHOULD NOT +xml" language. The media type reviewer should say something about this...

I guess the bottom line for me is: are applications actually going to use fragment identifiers--is there a commercial use case? Or is this just pontificating about stuff that won't actually get implemented?

If it's a real use case, do you want a uniform fragment identifier syntax across data syntaxes, so that #foo refers to the same semantic construct across +xml, +json, +cbor, etc.? And if so, why? (I get that "YANG provides an abstraction of datastore contents which we want to be independent of the various query response representations"; but, the YANG processors are representation-aware...so the mere fact that #xpointer-fragment-form and #json-fragment-form are different from each other, does not strike me as a big deal. The YANG processors know about XML vs. JSON so they have to do XML vs. JSON-specific things anyway.)

Sean

--------------D84EB749CE4BBD121E27DEAB-- From nobody Wed Jul 6 12:15:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562F812D1B8 for ; Wed, 6 Jul 2016 12:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gXCdHcCyv6Z for ; Wed, 6 Jul 2016 12:15:03 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130B112B040 for ; Wed, 6 Jul 2016 12:15:03 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id m127so257208904vkb.3 for ; Wed, 06 Jul 2016 12:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UIAiPSZPwzd2sm7x0NUVN5NvlAw2ow4KSGxUzgmVJnM=; b=Cj7w7+cyFwevEmf0EzvvnMDoJR4XMndKNyhYCdNv3AM3QvQ45wbs1t5ULoQhDGLygu b5COiE8q/MyfPgZprIrtNa3OU/3ESI3NT704UkyIaxF3tIe9P0UG3dpR8c5yjbCblnBQ aw7lWuPyaiigiX/M2scmYbFglGgmjMN4W7OeSpWW6EJfQscxnZ+dMRLS/zoHO8zezfqy XyXeE8UXrHl1br0Wtu5u7RKdVCpY3Gdnda7nlHnthU0VED/hLvUZoMBL9h6lQmkhaLaF mdOPwoEsk2bOussC4O6T5F8uiOdKtidsAJofV72uBR22PFvUM5yEsc+APJghr4GZgn36 Da0g== 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; bh=UIAiPSZPwzd2sm7x0NUVN5NvlAw2ow4KSGxUzgmVJnM=; b=FYHCtRBfcDOY7Ip0LnO4Clr0qCbSDGzfc4Tu7PfOGI2Iz8o6i7rNkh9sX4+HMnz9HT 7MScYK1R1dxPX4qbxz26Ho7nEhs7cgJeOMFfA/0UUI759oYLYKWvQSh7C7U23wVMOFbP BLigkNdwd86whL874poKxCTFQ0cQkiXGvP5DgULyj67vzMGuUKLZFaJbwB089cy4vjsX /C5sKwdy4AwWsLGjryiaqnN/k7pS+t/roznpHVK4xUPu6dZvCe+BagdTWnjSSXIdUGWE 6b2FG+I4PCOjl1JkF8ccMC1m68pcb3N+zw1o9DJxNqinWP9AsJWPdvmhGTnjOKvDODu9 3sfA== X-Gm-Message-State: ALyK8tKOKCtDBetZHnVt0sgwuoaASnreRqqOOcMHfzha70oxeUtPA5B4oBkd6x2mgtBr16jwadz8gpsvHcNlZg== X-Received: by 10.31.9.65 with SMTP id 62mr10577870vkj.89.1467832501875; Wed, 06 Jul 2016 12:15:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 6 Jul 2016 12:15:01 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 6 Jul 2016 12:15:01 -0700 Message-ID: To: "Steve Truong (struong)" Content-Type: multipart/alternative; boundary=001a11440b64dd697a0536fc62c9 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-patch-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 19:15:05 -0000 --001a11440b64dd697a0536fc62c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Actually the target-resource-offset typedef does not support JSON encoding, just XPath for XML encoding. This will be fixed in the next release. For XML: (use XML prefixes) edit1: /foo:X edit2: /bar:X For JSON: (use YANG module name) edit1: "target" : "/foo-mod:X" edit2: "target" : "/bar-mod:X" Andy On Wed, Jul 6, 2016 at 11:41 AM, Steve Truong (struong) wrote: > Yang Patch operation can target a datastore resource. Can we add > examples of datastore patching where multiple YANG modules are involved (= we > need to have at least 2 modules for the demonstration)? > > > > The module ietf-yang-patch > > doesn=E2=80=99t seem to be compilable? Should it? > > > > Thanks, > > steve > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11440b64dd697a0536fc62c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Actually the target-resource-offset= typedef does not support JSON encoding,
just XPath for XML encod= ing.=C2=A0 This will be fixed in the next release.


For XML: (use XML prefixes)

edit1:=
=C2=A0 <target xmlns:foo=3D"foo-namespace-uri">/= foo:X</target>

edit2:
=C2=A0 = <target xmlns:bar=3D"bar-namespace-uri">/bar:X</target&g= t;


For JSON: (use YANG module= name)

edit1:
=C2=A0 "target&q= uot; : "/foo-mod:X"

edit2:
=C2=A0"target" : "/bar-mod:X"
<= br>

Andy


On Wed, Jul 6, 2016 at 11:41 AM,= Steve Truong (struong) <struong@cisco.com> wrote:

Yang Patch operation can target a datastore resource= .=C2=A0=C2=A0 Can we add examples of datastore patching where multiple YANG= modules are involved (we need to have at least 2 modules for the demonstra= tion)?

=C2=A0

The module ietf-yang-patch doesn=E2=80=99t seem to be compilable?=C2=A0 Sho= uld it?

=C2=A0

Thanks,

steve


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


--001a11440b64dd697a0536fc62c9-- From nobody Wed Jul 6 13:25:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D412D67F for ; Wed, 6 Jul 2016 13:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtsGryG9jhax for ; Wed, 6 Jul 2016 13:25:39 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE89C12D686 for ; Wed, 6 Jul 2016 13:25:38 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id b192so20310424vke.0 for ; Wed, 06 Jul 2016 13:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5TwMideSU5s3j7Sk1kE+34vFGKVyHWHO33lF8ZRVBS8=; b=10xlkPxsS0IdSreFdHqxckD7YRtqeu/wh6dWiDoKztbqteWh5rr5TeYSWycP0v4jOT IVh/aO0YxuJWKsDtQJFHSLA5YEQv82XKFK7S/TxKXX/EkDINqFX/0rx9CJESoRxngxUf cI7LEaaHBoCf+UV08GO/xSnPZ0tIsBE7EPY4tM6muCyG0fo9S40/8FB8XyYAEW7zccEC 8V6gaUbAZ9A2vfH/sDf/MfEyDTs3LNsuYDuM6OqD4t13w1aaL+53l6dRsxenEh+/vu5O xqVW86B5iD0u0SvFjomb+p5QEC38JGNcFg1MgYtv1F626EI+VBPj1od6YkBg1/tRK41g epSg== 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; bh=5TwMideSU5s3j7Sk1kE+34vFGKVyHWHO33lF8ZRVBS8=; b=Avgsrf40ArbZjX858NFxkJjxm9tOEiNdM86U5zmavv8LnWqvMtxJ3gWmijlSafhzWR cAa6qQ1/vfi1sO4oJeiSP6PZX1/G3kKiXUoyUqIuLGqtm8G3j1ezx0zJrbfDmuN/eDQg cpFsoxWgBAGCRhUVnF4uDhXCJ5E4YlnF/BZ5ReauKuORqK67CiVFiQShhEhdGOOF3FHh nuNhOjv5N29Qm8kZn7Ni08seYaAOAruyctRvwcAO9cR9C5jZeap0fw1yQhr8bYZ3SaST 5SX3tfsIoXXQYFYjO3e6TO+T1Yfwo8IUoxKagtWCDGnp/EZxLtXyJavf4pRSW4g/9MwW dYLA== X-Gm-Message-State: ALyK8tLQxxHxJ/V1vj5FOvO4ULbCa7N+BNekVgW7zeA29oxBEmhRG5XqDNc6xYdAZpgjIgCm0LNpSuL/++rWog== X-Received: by 10.159.55.204 with SMTP id q70mr8936733uaq.16.1467836738008; Wed, 06 Jul 2016 13:25:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 6 Jul 2016 13:25:37 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 6 Jul 2016 13:25:37 -0700 Message-ID: To: "Steve Truong (struong)" Content-Type: multipart/alternative; boundary=94eb2c04cbfa5bd1270536fd5fc5 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Comments on draft-ietf-netconf-yang-patch-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 20:25:41 -0000 --94eb2c04cbfa5bd1270536fd5fc5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2016 at 12:15 PM, Andy Bierman wrote: > Hi, > > Actually the target-resource-offset typedef does not support JSON encodin= g, > just XPath for XML encoding. This will be fixed in the next release. > > After a little more thought, I would like to change this typedef so it always uses the JSON encoding (same format as the target resource URI Andy > > For XML: (use XML prefixes) > > edit1: > /foo:X > > edit2: > /bar:X > > > For JSON: (use YANG module name) > > edit1: > "target" : "/foo-mod:X" > > edit2: > "target" : "/bar-mod:X" > > > Andy > > > On Wed, Jul 6, 2016 at 11:41 AM, Steve Truong (struong) > wrote: > >> Yang Patch operation can target a datastore resource. Can we add >> examples of datastore patching where multiple YANG modules are involved = (we >> need to have at least 2 modules for the demonstration)? >> >> >> >> The module ietf-yang-patch >> >> doesn=E2=80=99t seem to be compilable? Should it? >> >> >> >> Thanks, >> >> steve >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > --94eb2c04cbfa5bd1270536fd5fc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 6, 2016 at 12:15 PM, Andy Bierman <andy@yumaworks.com= > wrote:
Hi,
Actually the target-resource-offset typedef does not supp= ort JSON encoding,
just XPath for XML encoding.=C2=A0 This will b= e fixed in the next release.


After a little more thought, I would like to ch= ange this typedef
so it always uses the JSON encoding (same forma= t as the target resource URI


Andy
=C2=A0
<= /div>

For XML: (use XML prefixes)

edit1:
=C2=A0 <target xmlns:foo=3D"foo-namespace-uri&q= uot;>/foo:X</target>

edit2:
=C2=A0 <target xmlns:bar=3D"bar-namespace-uri">/bar:X<= /target>


For JSON: (use YA= NG module name)

edit1:
=C2=A0 "= ;target" : "/foo-mod:X"

edit2:=
=C2=A0"target" : "/bar-mod:X"


Andy


On Wed, Jul 6, 2016 at = 11:41 AM, Steve Truong (struong) <struong@cisco.com> wrote:<= br>

Yang Patch operation can target a datastore resource= .=C2=A0=C2=A0 Can we add examples of datastore patching where multiple YANG= modules are involved (we need to have at least 2 modules for the demonstra= tion)?

=C2=A0

The module ietf-yang-patch doesn=E2=80=99t seem to be compilable?=C2=A0 Sho= uld it?

=C2=A0

Thanks,

steve


_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf



--94eb2c04cbfa5bd1270536fd5fc5-- From nobody Wed Jul 6 14:59:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92E812D0A2 for ; Wed, 6 Jul 2016 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II2eta34SRKF for ; Wed, 6 Jul 2016 14:59:32 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E8112B05D for ; Wed, 6 Jul 2016 14:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WLxdkl7101FmdJQF0lo9vNpD2Fz3jglf4GcqX5EU7ns=; b=ELj3kprUSDx6CTzxBySb3RkbFVjt4pTngKkFKClPT+D/Q3OKrLS4TyQ0ciIHoEDRC1eH5O5ghyBiS23bq7DV/aQcbGCoxsRgggIPTe4SNq+2GoBvydmzaSNauVXTAaCipbUGfUe1db0+jscSD1dlLfybUJld/n9tWcxqf5nVZKY= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 6 Jul 2016 21:59:30 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.022; Wed, 6 Jul 2016 21:59:29 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch/13: Signature over YANG data? Thread-Index: AQHR0lbqRF2CE0HA502XoIUgUCHuKqALu5kA Date: Wed, 6 Jul 2016 21:59:29 +0000 Message-ID: <5EF4CAA8-4088-445D-83B5-2BFED8C24410@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 635862e7-88ce-4991-181f-08d3a5e8ce32 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:euBkEd/fuVcESLC0sFjhSoLyp2HMUN/a+pNzjIdld2650KfZwtuHXhTKoTxujigSghNwQED3mCwyHRR9n2VJvKHEIpu5FZgQt413g+TjT9alP34i8hbSrXaG4cN1SkUNf3DF8CZLCDsU10k17OgcW5fqAdfE4lRhjJ3LopqaXAYz1p5oCwrC/aij1K2jUrDQhBeQxz9SbX+RtwaHbXbeCfPynXf4XKJRlDvNL/dlgy95c1BZYXaBMBJjHGRI9zn8SoevGGeo08dcbcQlHar8VIGY1hWA4zBiS+hSdu67KXFd/rCazGhOmRRZAEYxM7pE8SaCuma/I1ML8IdBIcmO6A==; 5:MB3uYhnuoHfIcBrS6cUSM++a1beBGLjpXp9wUg9lxXMSh7tUmQX9+4UmX0LVEeZrNCibfWlnPctaR/b5yl+kAKsOclhZZUxBZ+C3pBSMJCsAgu1qHUQQbl27QgPrGZwqCRlCum5eHixi0IkjBFzPng==; 24:2vJo1h2YLJb8y6fipOedyYUW+3rZRH0C+m08DjOO6hmzTTZEayo84jus1rAxPYnOTvN6F/xQQYFd22R1tQQtLCDfOVyrjYF88wxWLt5Tvgk=; 7:e+oeradU1x6PO+qIFwDD9vGuWsAusr+Nzzw5iJGCJvSbtZZOCxjC8+VRMTduOSIwdPjvACwazivucuytLhsv5MeK5jACjuekEF4/lf+1OLgAk2xyN2YfAhXwp2l1eUvRWv8cFVLedtXg+LcZKI5FeagbIp0suxAYJsL4lE0EoHks1p78KzmT/zXQSDAuMEahkHe6xkrhkq1a0DHEEYutcqiDGSkLsJ2TIz+R9T0FTHk+AXsB55fvasyhsjxdd9Zm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(131327999870524)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(52314003)(189002)(43544003)(199003)(2900100001)(106356001)(19625215002)(66066001)(2501003)(107886002)(122556002)(110136002)(99286002)(10400500002)(7906003)(68736007)(19617315012)(82746002)(105586002)(2906002)(15975445007)(106116001)(33656002)(101416001)(2950100001)(3660700001)(83506001)(189998001)(77096005)(450100001)(5640700001)(7846002)(87936001)(4001350100001)(19580405001)(81156014)(19300405004)(3280700002)(16236675004)(586003)(102836003)(6116002)(3846002)(83716003)(81166006)(1730700003)(92566002)(8936002)(19580395003)(7736002)(97736004)(76176999)(50986999)(54356999)(2351001)(5002640100001)(86362001)(8676002)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5EF4CAA84088445D83B52BFED8C24410junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2016 21:59:29.8596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452 Archived-At: Subject: Re: [Netconf] zerotouch/13: Signature over YANG data? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:59:36 -0000 --_000_5EF4CAA84088445D83B52BFED8C24410junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIHNwZW50IHNvbWUgdGltZSB0b2RheSB0cnlpbmcgdG8gZ2V0IHRoaXMgcGtjcyM3IGlkZWEg dG8gd29yay4gICBJ4oCZbSBhYmxlIHRvIGdldCB0aGUgc2lnbmVkLWRhdGEgY2FzZSB3b3JraW5n IHVzaW5nIHN0YW5kYXJkIE9wZW5TU0wgY29tbWFuZCBsaW5lLCBidXQgaXQgc2VlbXMgdGhhdCBn ZXR0aW5nIHRoZSB1bnNpZ25lZC1kYXRhIGNhc2Ugd29ya2luZyByZXF1aXJlcyB3cml0aW5nIGNv ZGUuICBGb3IgdGhlIOKAmEPigJkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UsIGl0IGxvb2tzIGxpa2Ug ZWRpdGluZyB0aGUgb3BlbnNzbC0xLjAuMmcvYXBwcy9zbWltZS5jIGZpbGUgd2lsbCBkbyBpdC4g IFNpbWlsYXIgd291bGQgaGF2ZSB0byBiZSBkb25lIGZvciBvdGhlciBwcm9ncmFtbWluZyBsYW5n dWFnZXMgKGUuZy4sIEphdmEsIFB5dGhvbikuICBSZWNhbGwgdGhhdCBib3RoIHNpZGVzLCB0aGUg Y29udHJvbGxlciBhcHBsaWNhdGlvbiBhbmQgdGhlIGRldmljZSwgd291bGQgbmVlZCB0byBoYXZl IHRoaXMgY29kZSB3cml0dGVuLCBoZW5jZSB0aGUgZGVzaXJlZCBmb3IgbGFuZ3VhZ2UgcG9ydGFi aWxpdHkuLi4NCg0KRm9yIG5vdyBJ4oCZbGwgbGVhdmUgdGhpcyBpZGVhIChhbHdheXMgdXNpbmcg cGtjcyM3KSBhcyBhbiBvcHRpb24gZm9yIHVzIHRvIGNvbnNpZGVyLiAgIFRvIGNvbXBsZXRlIHRo ZSBsaXN0IG9mIG9wdGlvbnMgY3VycmVudGx5IG9uIHRoZSB0YWJsZSwgSSBhZGRlZCBpbiBhbHNv IHRoZSBpZGVhIG9mIHVzaW5nIFhNTFNJRyBhbmQgSk9TRS4gIFJlY2FsbCB0aGlzIHdhcyB0aGUg YXBwcm9hY2ggd2UgdXNlZCBlYXJsaWVyLCBidXQgZGlkbuKAmXQgbGlrZSBiZWNhdXNlIG9mIHRo ZSBoZWF2eSBkZXBlbmRlbmN5IG9uIHRob3NlIHhtbC9qc29uIGxpYnJhcmllcy4gIEFueXdheSwg aGVyZeKAmXMgdGhlIGNvbXBsZXRlIGxpc3Qgbm93Og0KDQpPcHRpb25zOg0KDQoxLiAgICAgICBL ZWVwIGFzIGlzIChlLmcuLCBmb3JjZSBkZXZpY2UgdG8gdHJ5IGJvdGggVVJMIHJlc291cmNlcykg ICAvLyB1cCB0byAzIHJvdW5kIHRyaXBzIGluc3RlYWQgb2YganVzdCBvbmUNCg0KMi4gICAgICAg RGVmaW5lIGEgY2Fub25pY2FsIGZvcm1hdCBmb3IgWE1MIGFuZCBKU09OIGVuY29kaW5ncyAgIC8v IE5vdCBzdXJlIGlmIHRoaXMgaXMgZXZlbiBwb3NzaWJsZeKApg0KDQozLiAgICAgICBEZWZpbmUg YW4gZW5jb2RpbmctaW5kZXBlbmRlbnQgc2lnbmF0dXJlIGFsZ29yaXRobSAgICAgIC8vIHRyaWNr eSB0byBkZWZpbmUsIG5vdCBlYXN5IHRvIGltcGxlbWVudA0KDQo0LiAgICAgICBFbmNvZGUgYm90 aCByZXNvdXJjZXMgaW4gYSBsZWFmIGhhdmluZyB0eXBlIOKAnHN0cmluZ+KAnSAgICAgICAgLy8g ZXZlbiB0aG91Z2ggaXTigJlzIFlBTkctZW5jb2RlZCBkYXRhDQoNCjUuICAgICAgIGFsd2F5cyBy ZXR1cm4gYSBwa2NzIzcgc3RydWN0dXJlLCBlaXRoZXIgc2lnbmVkIG9yIHVuc2lnbmVkICAvLyB1 bnNpZ25lZCBpcyBoYXJkIHRvIGltcGxlbWVudA0KDQo2LiAgICAgICB1c2UgWE1MU0lHIGFuZCBK T1NFIChmb3IgWE1MIGFuZCBKU09OIHJlc3BlY3RpdmVseSkgICAgICAgICAgICAgLy8gZGVwZW5k ZW5jeSBvbiBoZWF2eSBYTUwvSlNPTiBsaWJyYXJpZXMNCg0KSeKAmW0gdGhpbmsgdGhhdCBvcHRp b24gIzIgaXMgZmxhd2VkLiAgVGhhdCBpcywgZXZlbiBoYXZpbmcgYSBjYW5vbmljYWwgZm9ybWF0 IHdvbuKAmXQgaGVscCBiZWNhdXNlIHRoZSBjbGllbnQgY2FuIHJlcXVlc3QgdGhlIHNlcnZlciBy ZXR1cm4gWE1MIG9yIEpTT04sIGJ1dCBsaWtlbHkgdGhlIGRhdGEgaXMgc2lnbmVkIG92ZXIganVz dCBvbmUsIHVubGVzcyB0aGUgc2VydmVyIGhhcyBhbiBhYmlsaXR5IHRvIHNpZ24gdGhlIGRhdGEg ZHluYW1pY2FsbHkgKGkuZS4sIGl0IHBvc3Nlc3NlcyB0aGUgcHJpdmF0ZSBrZXkgdG8gdGhlIG93 bmVyIGNlcnRpZmljYXRlKSwgd2hpY2ggaXMgYSBodWdlIGFzc3VtcHRpb24gdG8gbWFrZS4gICBP bmUgb3B0aW9uIHRvIGZpeGluZyB0aGlzIGlzIHRvIHNheSB0aGUgUkVTVENPTkYgc2VydmVyIGNh biBvbmx5IHNlcnZlIFhNTCBvciBKU09OIGVuY29kaW5nLCBidXQgSeKAmW0gdW5zdXJlIGlmIHRo aXMgd2lsbCBiZSBhIHBvcHVsYXIgaWRlYSBlaXRoZXIuLi4NCg0KVGhhbmtzLA0KS2VudA0KDQoN CkZyb206IE5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtl bnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDI5 LCAyMDE2IGF0IDY6MzggUE0NClRvOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHplcm90b3VjaC8xMzogU2lnbmF0dXJlIG92ZXIg WUFORyBkYXRhPw0KDQpUcnlpbmcgdG8gbW92ZSB0aGlzIGRpc2N1c3Npb24gZm9yd2FyZC4uLg0K DQpBbiBpZGVhIG5vdCBsaXN0ZWQgYmVsb3cgaXMgZm9yIHRoZSDigJhzaWduYXR1cmXigJkgdmFs dWUgKGkuZS4gYSBwa2NzIzcgc3RydWN0dXJlKSB0byBhbHdheXMgZW52ZWxvcCB0aGUgYm9vdHN0 cmFwcGluZyBkYXRhLiAgVGhhdCBpcywgd2XigJlkIHJlbW92ZSB0aGUg4oCccmVkaXJlY3QtaW5m b3JtYXRpb27igJ0gYW5kIOKAnGJvb3RzdHJhcC1pbmZvcm1hdGlvbuKAnSBmcm9tIHRoZSBkYXRh LW1vZGVsIC8gQVBJLiAgTW9yZSBzcGVjaWZpY2FsbHk6DQoNCk9MRDoNCg0KICBtb2R1bGU6IGll dGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXINCiAgICAgICstLXJvIGRldmljZXMNCiAgICAg ICAgICstLXJvIGRldmljZSogW3VuaXF1ZS1pZF0NCiAgICAgICAgICAgICstLXJvIHVuaXF1ZS1p ZCAgICAgICAgIHN0cmluZw0KICAgICAgICAgICAgKy0tcm8gKHR5cGUpPw0KICAgICAgICAgICAg fCAgKy0tOihyZWRpcmVjdC1pbmZvcm1hdGlvbikNCiAgICAgICAgICAgIHwgIHwgICstLS4uLg0K ICAgICAgICAgICAgfCAgKy0tOihib290c3RyYXAtaW5mb3JtYXRpb24pDQogICAgICAgICAgICB8 ICAgICArLS0uLi4NCiAgICAgICAgICAgICstLXJvIHNpZ25hdHVyZT8gICAgICAgIGJpbmFyeSAg Ly8gYW4gb3B0aW9uYWwgZGV0YWNoZWQgc2lnbmF0dXJlIHVzaW5nIHBrY3MjNw0KICAgICAgICAg ICAgLi4uDQoNCk5FVzoNCg0KICBtb2R1bGU6IGlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2 ZXINCiAgICAgICstLXJvIGRldmljZXMNCiAgICAgICAgICstLXJvIGRldmljZSogW3VuaXF1ZS1p ZF0NCiAgICAgICAgICAgICstLXJvIHVuaXF1ZS1pZCAgICAgICAgIHN0cmluZw0KICAgICAgICAg ICAgKy0tcm8gYm9vdHN0cmFwLWRhdGEgICAgYmluYXJ5ICAvLyBhIG1hbmRhdG9yeSBwa2NzIzcg c3RydWN0dXJlIHRoYXQgd3JhcHMgdGhlIHNhbWUgZGF0YQ0KICAgICAgICAgICAgLi4uDQoNClNv bWUgY29tbWVudHM6DQoNCjEpIHRoaXMgQVBJIGlzIGZvciB0aGUgYm9vdHN0cmFwIHNlcnZlcuKA mXMgU0JJIChzb3V0aGJvdW5kIGFwaSkgZmFjaW5nIGRldmljZXM7IGl0IGlzIHJlYWQtb25seSBh bmQgdGh1cyBkb2VzIG5vdCBoYXZlIHRvIGJlIHVzZXItZnJpZW5kbHkuDQoNCjIpIFRob3VnaCB0 aGUgemVyb3RvdWNoIGRyYWZ0IHNheXMgdGhlIG5vcnRoYm91bmQgaW50ZXJmYWNlIGlzIG91dC1v Zi1zY29wZSwgaXQgd291bGQgc2VlbSB1c2VmdWwgZm9yIGEgYm9vdHN0cmFwIHNlcnZlcuKAmXMg TkJJIHRvIHRha2UgY2FyZSBvZiBnZW5lcmF0aW5nIHRoZSBwcml2YXRlLWtleSBhbmQgQ1NSIGFu ZCwgbGF0ZXIsIHNpZ25pbmcgYm9vdHN0cmFwcGluZyBkYXRhLiAgVGhhdCBpcywgdGhlIE5CSSBm b3IgYSBib290c3RyYXAgc2VydmVyIG1pZ2h0IHJldGFpbiB0aGUg4oCcdXNlci1mcmllbmRseeKA nSBBUEkgZGVmaW5lZCBieSB0aGUgY3VycmVudCBZQU5HIG1vZGVsICh3aGVyZSB0aGUgdHJlZS1z dHJ1Y3R1cmUgZWxlbWVudHMgYXJlIHdyaXRhYmxlKSB3aGlsZSBpbnRlcm5hbGx5IGhhdmluZyBs b2dpYyB0byBkeW5hbWljYWxseSBjcmVhdGUgKHNpZ25lZCBvciB1bnNpZ25lZCkgcGtjcyM3IHN0 cnVjdHVyZXMgZm9yIGRldmljZXMgdG8gb2J0YWluLg0KDQozKSB0aGlzIGFwcHJvYWNoIGhhcyB0 aGUgZG93bnNpZGUgb2YgZm9yY2luZyBib290c3RyYXAgc2VydmVycyB0byBhbHdheXMgc2VydmUg cGtjcyM3IHN0cnVjdHVyZXMsIGV2ZW4gd2hlbiB0aGUgZGF0YSBpcyB1bnNpZ25lZCwgYXMgb3Bw b3NlZCB0byBvbmx5IHdoZW4gc2lnbmVkIGRhdGEgaXMgbmVlZGVkIChhcyB0aGUgY3VycmVudCBk cmFmdCBoYXMgaXQpLiAgUGVyaGFwcyBub3QgYSBiaWcgZGVhbCwgYnV0IGl0IGRvZXMgaW5jcmVh c2UgdXBmcm9udCBkZXZlbG9wbWVudCBjb3N0cy4NCg0KNCkgdGhpcyBhcHByb2FjaCBoYXMgdGhl IHVwc2lkZSBvZiBkZWZpbmluZyBhIG5pY2UgYXJ0aWZhY3QgZW5jb2RpbmcgZm9yIGJvdGggcmVt b3ZhYmxlIG1lZGlhIGFuZCBESENQLCBidXQgd2l0aCB0aGUgZG93bnNpZGUgb2YgY29tcGxpY2F0 aW5nIEROUyBtYXBwaW5ncy4gIFNpbXBsZSBpcyB0aGUgc29sdXRpb24gZGVzY3JpYmVkIGluIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA4 I3NlY3Rpb24tNC4yLCBidXQgd2UgY291bGQgYml0ZSB0aGUgYnVsbGV0IGFuZCBpbnN0ZWFkICpy ZXBsYWNlKiB0aGUgZmlyc3QgZm91ciBlbnRyaWVzIGxpc3RlZCAoaG9zdG5hbWUgKyBwb3J0ICsg YW5jaG9yICsgc2lnbmF0dXJlKSB3aXRoIGEgc2luZ2xlIFRYVCByZWNvcmQgZW5jb2RpbmcgdGhl IGZvdXIgdmFsdWVzIGludG8gYSBwa2NzIzcgc3RydWN0dXJlLiAgVGhhdCBpcywgdGhlcmUgd291 bGQgYmUgKm5vKiBTUlYgcmVjb3JkcywuICBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBhbGxvdyBm b3IgcmVkdW5kYW50IGRhdGEgaW4gU1JWIHJlY29yZHMsIHdoaWNoIHdvdWxkIGJlIG5pY2UgZm9y IHdoZW4gdGhlIGRhdGEgaXMgdW5zaWduZWQuDQoNClRob3VnaHRzPw0KDQpLZW50DQoNCg0KRnJv bTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2VudCBX YXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAxMSwgMjAx NiBhdCA3OjIwIFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3JnPg0K U3ViamVjdDogW05ldGNvbmZdIHplcm90b3VjaC8xMzogU2lnbmF0dXJlIG92ZXIgWUFORyBkYXRh Pw0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xMw0K DQoNCg0KU2xpZGUgIzExIHByZXNlbnRlZCBkdXJpbmcgdGhlIElFVEYgOTUgbWVldGluZyBzYWlk Og0KDQo9PT09PVNUQVJUPT09PT0NCkN1cnJlbnQgdGV4dCBzYXlzIHRoYXQgdGhlIHNpZ25hdHVy ZSBpcyBvdmVyIHRoZSBkYXRhIGluIHdoYXRldmVyIGZvcm0gaXTigJlzIHByb3ZpZGVkIChYTUwg b3IgSlNPTikNCg0KVGhpcyB3b3JrcyBncmVhdCBmb3IgYWxsIHNvdXJjZXMgb2YgYm9vdHN0cmFw cGluZyBkYXRhIGJ1dCwgZm9yIHRoZSBib290c3RyYXAgc2VydmVyLCByZXF1aXJlcyB0aGF0IGJv dGggdGhlIG5vcnRoYm91bmQgYXBwbGljYXRpb24gYW5kIHRoZSBkZXZpY2UgYWNjZXNzIHNwZWNp ZmljIFVSTCByZXNvdXJjZXM6DQovaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZlcjpkZXZp Y2VzL2RldmljZT0xMjM0NTYvcmVkaXJlY3QtaW5mb3JtYXRpb24NCi9pZXRmLXplcm90b3VjaC1i b290c3RyYXAtc2VydmVyOmRldmljZXMvZGV2aWNlPTEyMzQ1Ni9ib290c3RyYXAtaW5mb3JtYXRp b24NCg0KQnV0IHRoaXMgYXBwcm9hY2ggaGFzIGlzc3VlczoNCg0KICAqICAgU2VydmVyIE1VU1Qg Tk9UIGNoYW5nZSBpdHMgZW5jb2RpbmcgaW4gYW55IHdheSBiZXR3ZWVuIHRoZSB0aW1lIHRoZSBk YXRhIHdhcyBzYXZlZCBhbmQgd2hlbiB0aGUgZGV2aWNlIHJldHJpZXZlcyB0aGUgZGF0YQ0KICAq ICAgVGhlc2UgdHdvIHJlc291cmNlcyBhcmUgdW5kZXIgYSBjaG9pY2Ugbm9kZSwgYW5kIHRoZSBk ZXZpY2UgZG9lc27igJl0IGtub3cgdXAgZnJvbnQgd2hpY2ggd2lsbCBiZSBwcmVzZW50Lg0KICAq ICAgSXQgaXMgZGVzaXJhYmxlIGZvciBkZXZpY2UgdG8ganVzdCBmZXRjaCB0aGUgdG9wLWxldmVs IOKAnGRldmljZeKAnSByZXNvdXJjZSwgdG8gZ2V0IGV2ZXJ5dGhpbmcgaW4gb25lIHJlcXVlc3QN Cg0KT3B0aW9uczoNCg0KICAqICAgS2VlcCBhcyBpcyAoZS5nLiwgZm9yY2UgZGV2aWNlIHRvIHRy eSBib3RoIFVSTCByZXNvdXJjZXMpIC8vIHVwIHRvIDMgcm91bmQgdHJpcHMgaW5zdGVhZCBvZiBq dXN0IG9uZQ0KICAqICAgRGVmaW5lIGEgY2Fub25pY2FsIGZvcm1hdCBmb3IgWE1MIGFuZCBKU09O IGVuY29kaW5ncyAvLyBOb3Qgc3VyZSBpZiB0aGlzIGlzIGV2ZW4gcG9zc2libGXigKYNCiAgKiAg IERlZmluZSBhbiBlbmNvZGluZy1pbmRlcGVuZGVudCBzaWduYXR1cmUgYWxnb3JpdGhtICAgICAg Ly8gdHJpY2t5IHRvIGRlZmluZSwgbm90IGVhc3kgdG8gaW1wbGVtZW50DQogICogICBFbmNvZGUg Ym90aCByZXNvdXJjZXMgaW4gYSBsZWFmIGhhdmluZyB0eXBlIOKAnHN0cmluZ+KAnSAgICAgICAv LyBldmVuIHRob3VnaCBpdOKAmXMgWUFORy1lbmNvZGVkIGRhdGENCg0KVGhvdWdodHM/DQo9PT09 PVNUT1A9PT09PQ0KDQpJbiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHNsaWRlLCBKZWZmIEhhYXMg bm90ZWQgdGhhdCBQS0NTIzkgaXMgcG9wdWxhciBpbiB0aGUgSUVURiBhbmQgdGhhdCBoZSBmZWx0 IHRoYXQgY2Fub25pY2FsaXphdGlvbiBtaWdodCBiZSBhIHJlcXVpcmVtZW50LiBCdXQgS2VudCBu b3RlZCB0aGF0IGNhbm9uaWNhbGl6YXRpb24gaXMgcHJhY3RpY2FsbHkgaW1wb3NzaWJsZSBnaXZl biB0aGF0IFhNTC9KU09OIGhhcyBubyBndWFyYW50ZWVkIG9yZGVyaW5nIG9mIHRyZWUgbm9kZXMu DQoNCkkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhIGdvb2Qgc29sdXRpb24geWV0Li4uDQoNCg0KDQoN Cg0KS2VudA0KDQoNCg== --_000_5EF4CAA84088445D83B52BFED8C24410junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3D4C05132EFDA04BBF29D01211A2A9BF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFu b3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjg5MjExMzQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE0NjY3MTI0MjAgNjc2OTg3MDMgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTUwMjkwMzc3Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk1MDg0MDE5NCA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo1NDQ3NTk3ODg7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjE5MDM0OTI1Mzg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJ e21zby1saXN0LWlkOjgyMzU0ODUxMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTc5NTAzNzMy Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjg3MDA3NDg3NjsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6OTM4ODk0MzkwO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0K CXttc28tbGlzdC1pZDoxODQ2NjIzOTE1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTAwMjgw NTA3Mjt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1Omxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1 OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5JIHNwZW50IHNvbWUgdGltZSB0b2RheSB0cnlpbmcgdG8gZ2V0 IHRoaXMgcGtjcyM3IGlkZWEgdG8gd29yay4mbmJzcDsmbmJzcDsgSeKAmW0gYWJsZSB0byBnZXQg dGhlIHNpZ25lZC1kYXRhIGNhc2Ugd29ya2luZyB1c2luZyBzdGFuZGFyZCBPcGVuU1NMIGNvbW1h bmQgbGluZSwgYnV0IGl0IHNlZW1zIHRoYXQgZ2V0dGluZyB0aGUgdW5zaWduZWQtZGF0YQ0KIGNh c2Ugd29ya2luZyByZXF1aXJlcyB3cml0aW5nIGNvZGUuJm5ic3A7IEZvciB0aGUg4oCYQ+KAmSBw cm9ncmFtbWluZyBsYW5ndWFnZSwgaXQgbG9va3MgbGlrZSBlZGl0aW5nIHRoZSBvcGVuc3NsLTEu MC4yZy9hcHBzL3NtaW1lLmMgZmlsZSB3aWxsIGRvIGl0LiZuYnNwOyBTaW1pbGFyIHdvdWxkIGhh dmUgdG8gYmUgZG9uZSBmb3Igb3RoZXIgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzIChlLmcuLCBKYXZh LCBQeXRob24pLiZuYnNwOyBSZWNhbGwgdGhhdCBib3RoIHNpZGVzLCB0aGUNCiBjb250cm9sbGVy IGFwcGxpY2F0aW9uIGFuZCB0aGUgZGV2aWNlLCB3b3VsZCBuZWVkIHRvIGhhdmUgdGhpcyBjb2Rl IHdyaXR0ZW4sIGhlbmNlIHRoZSBkZXNpcmVkIGZvciBsYW5ndWFnZSBwb3J0YWJpbGl0eS4uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkZvciBub3cgSeKAmWxsIGxlYXZlIHRoaXMgaWRlYSAo YWx3YXlzIHVzaW5nIHBrY3MjNykgYXMgYW4gb3B0aW9uIGZvciB1cyB0byBjb25zaWRlci4mbmJz cDsgJm5ic3A7VG8gY29tcGxldGUgdGhlIGxpc3Qgb2Ygb3B0aW9ucyBjdXJyZW50bHkgb24gdGhl IHRhYmxlLCBJIGFkZGVkIGluIGFsc28gdGhlIGlkZWEgb2YgdXNpbmcgWE1MU0lHIGFuZA0KIEpP U0UuJm5ic3A7IFJlY2FsbCB0aGlzIHdhcyB0aGUgYXBwcm9hY2ggd2UgdXNlZCBlYXJsaWVyLCBi dXQgZGlkbuKAmXQgbGlrZSBiZWNhdXNlIG9mIHRoZSBoZWF2eSBkZXBlbmRlbmN5IG9uIHRob3Nl IHhtbC9qc29uIGxpYnJhcmllcy4mbmJzcDsgQW55d2F5LCBoZXJl4oCZcyB0aGUgY29tcGxldGUg bGlzdCBub3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+T3B0aW9uczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvOCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktlZXAgYXMgaXMgKGUuZy4sIGZvcmNlIGRldmljZSB0 byB0cnkgYm90aCBVUkwgcmVzb3VyY2VzKSAmbmJzcDsmbmJzcDsvLyB1cCB0byAzIHJvdW5kIHRy aXBzIGluc3RlYWQgb2YganVzdCBvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvOCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkRlZmluZSBhIGNhbm9uaWNhbCBmb3JtYXQgZm9yIFhNTCBhbmQgSlNPTiBlbmNvZGluZ3Mg Jm5ic3A7Jm5ic3A7Ly8gTm90IHN1cmUgaWYgdGhpcyBpcyBldmVuIHBvc3NpYmxl4oCmPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzgiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5EZWZpbmUgYW4gZW5jb2RpbmctaW5kZXBl bmRlbnQgc2lnbmF0dXJlIGFsZ29yaXRobSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAv LyB0cmlja3kgdG8gZGVmaW5lLCBub3QgZWFzeSB0byBpbXBsZW1lbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvOCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkVuY29kZSBib3RoIHJlc291cmNlcyBpbiBhIGxlYWYgaGF2 aW5nIHR5cGUg4oCcc3RyaW5n4oCdJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOy8vIGV2ZW4gdGhvdWdoIGl04oCZcyBZQU5HLWVuY29kZWQgZGF0YTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm84Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+YWx3YXlzIHJldHVybiBhIHBrY3MjNyBzdHJ1Y3R1 cmUsIGVpdGhlciBzaWduZWQgb3IgdW5zaWduZWQmbmJzcDsgLy8gdW5zaWduZWQgaXMgaGFyZCB0 byBpbXBsZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvOCI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ni48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPnVzZSBYTUxT SUcgYW5kIEpPU0UgKGZvciBYTUwgYW5kIEpTT04gcmVzcGVjdGl2ZWx5KSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsvLyBkZXBlbmRlbmN5IG9uIGhlYXZ5IFhNTC9KU09OIGxpYnJhcmllczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPknigJltIHRoaW5rIHRoYXQgb3B0aW9uICMyIGlzIGZsYXdlZC4mbmJzcDsg VGhhdCBpcywgZXZlbiBoYXZpbmcgYSBjYW5vbmljYWwgZm9ybWF0IHdvbuKAmXQgaGVscCBiZWNh dXNlIHRoZSBjbGllbnQgY2FuIHJlcXVlc3QgdGhlIHNlcnZlciByZXR1cm4gWE1MIG9yIEpTT04s IGJ1dCBsaWtlbHkgdGhlIGRhdGEgaXMgc2lnbmVkIG92ZXINCiBqdXN0IG9uZSwgdW5sZXNzIHRo ZSBzZXJ2ZXIgaGFzIGFuIGFiaWxpdHkgdG8gc2lnbiB0aGUgZGF0YSBkeW5hbWljYWxseSAoaS5l LiwgaXQgcG9zc2Vzc2VzIHRoZSBwcml2YXRlIGtleSB0byB0aGUgb3duZXIgY2VydGlmaWNhdGUp LCB3aGljaCBpcyBhIGh1Z2UgYXNzdW1wdGlvbiB0byBtYWtlLiZuYnNwOyZuYnNwOyBPbmUgb3B0 aW9uIHRvIGZpeGluZyB0aGlzIGlzIHRvIHNheSB0aGUgUkVTVENPTkYgc2VydmVyIGNhbiBvbmx5 IHNlcnZlIFhNTCBvciBKU09ODQogZW5jb2RpbmcsIGJ1dCBJ4oCZbSB1bnN1cmUgaWYgdGhpcyB3 aWxsIGJlIGEgcG9wdWxhciBpZGVhIGVpdGhlci4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5LZW50PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+TmV0Y29uZiAmbHQ7bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2t3 YXRzZW5AanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAy OSwgMjAxNiBhdCA2OjM4IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRjb25mQGlldGYub3Jn JnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W05ldGNvbmZdIHplcm90b3VjaC8xMzogU2lnbmF0dXJlIG92ZXIgWUFORyBkYXRhPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRy eWluZyB0byBtb3ZlIHRoaXMgZGlzY3Vzc2lvbiBmb3J3YXJkLi4uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+QW4gaWRlYSBub3QgbGlzdGVkIGJlbG93IGlzIGZvciB0aGUg4oCYc2lnbmF0dXJl 4oCZIHZhbHVlIChpLmUuIGEgcGtjcyM3IHN0cnVjdHVyZSkgdG8gYWx3YXlzIGVudmVsb3AgdGhl IGJvb3RzdHJhcHBpbmcgZGF0YS4mbmJzcDsgVGhhdCBpcywgd2XigJlkIHJlbW92ZSB0aGUg4oCc cmVkaXJlY3QtaW5mb3JtYXRpb27igJ0gYW5kIOKAnGJvb3RzdHJhcC1pbmZvcm1hdGlvbuKAnQ0K IGZyb20gdGhlIGRhdGEtbW9kZWwgLyBBUEkuJm5ic3A7IE1vcmUgc3BlY2lmaWNhbGx5Ojwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz cDsgbW9kdWxlOiBpZXRmLXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1ybyBkZXZpY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBk ZXZpY2UqIFt1bmlxdWUtaWRdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyYjNDM7LS1ybyB1bmlxdWUtaWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7c3RyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyAodHlwZSk/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLToocmVkaXJlY3QtaW5m b3JtYXRpb24pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLTooYm9vdHN0cmFwLWluZm9ybWF0aW9u KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0uLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIHNpZ25hdHVyZT8mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmluYXJ5Jm5ic3A7IC8vIGFuIG9wdGlvbmFsIGRl dGFjaGVkIHNpZ25hdHVyZSB1c2luZyBwa2NzIzc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TkVXOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyBtb2R1bGU6IGlldGYtemVyb3RvdWNoLWJv b3RzdHJhcC1zZXJ2ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIGRldmljZXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIGRldmljZSogW3VuaXF1ZS1pZF08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIHVuaXF1ZS1p ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJv IGJvb3RzdHJhcC1kYXRhJm5ic3A7ICZuYnNwOyZuYnNwO2JpbmFyeSZuYnNwOyAvLyBhIG1hbmRh dG9yeSBwa2NzIzcgc3RydWN0dXJlIHRoYXQgd3JhcHMgdGhlIHNhbWUgZGF0YTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5Tb21lIGNvbW1lbnRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjEpIHRo aXMgQVBJIGlzIGZvciB0aGUgYm9vdHN0cmFwIHNlcnZlcuKAmXMgU0JJIChzb3V0aGJvdW5kIGFw aSkgZmFjaW5nIGRldmljZXM7IGl0IGlzIHJlYWQtb25seSBhbmQgdGh1cyBkb2VzIG5vdCBoYXZl IHRvIGJlIHVzZXItZnJpZW5kbHkuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4y KSBUaG91Z2ggdGhlIHplcm90b3VjaCBkcmFmdCBzYXlzIHRoZSBub3J0aGJvdW5kIGludGVyZmFj ZSBpcyBvdXQtb2Ytc2NvcGUsIGl0IHdvdWxkIHNlZW0gdXNlZnVsIGZvciBhIGJvb3RzdHJhcCBz ZXJ2ZXLigJlzIE5CSSB0byB0YWtlIGNhcmUgb2YgZ2VuZXJhdGluZyB0aGUgcHJpdmF0ZS1rZXkg YW5kIENTUiBhbmQsIGxhdGVyLA0KIHNpZ25pbmcgYm9vdHN0cmFwcGluZyBkYXRhLiZuYnNwOyBU aGF0IGlzLCB0aGUgTkJJIGZvciBhIGJvb3RzdHJhcCBzZXJ2ZXIgbWlnaHQgcmV0YWluIHRoZSDi gJx1c2VyLWZyaWVuZGx54oCdIEFQSSBkZWZpbmVkIGJ5IHRoZSBjdXJyZW50IFlBTkcgbW9kZWwg KHdoZXJlIHRoZSB0cmVlLXN0cnVjdHVyZSBlbGVtZW50cyBhcmUgd3JpdGFibGUpIHdoaWxlIGlu dGVybmFsbHkgaGF2aW5nIGxvZ2ljIHRvIGR5bmFtaWNhbGx5IGNyZWF0ZSAoc2lnbmVkIG9yIHVu c2lnbmVkKQ0KIHBrY3MjNyBzdHJ1Y3R1cmVzIGZvciBkZXZpY2VzIHRvIG9idGFpbi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4zKSB0aGlzIGFwcHJvYWNoIGhhcyB0aGUgZG93bnNpZGUgb2Yg Zm9yY2luZyBib290c3RyYXAgc2VydmVycyB0byBhbHdheXMgc2VydmUgcGtjcyM3IHN0cnVjdHVy ZXMsIGV2ZW4gd2hlbiB0aGUgZGF0YSBpcyB1bnNpZ25lZCwgYXMgb3Bwb3NlZCB0byBvbmx5IHdo ZW4gc2lnbmVkIGRhdGEgaXMgbmVlZGVkIChhcyB0aGUgY3VycmVudA0KIGRyYWZ0IGhhcyBpdCku Jm5ic3A7IFBlcmhhcHMgbm90IGEgYmlnIGRlYWwsIGJ1dCBpdCBkb2VzIGluY3JlYXNlIHVwZnJv bnQgZGV2ZWxvcG1lbnQgY29zdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+NCkgdGhpcyBh cHByb2FjaCBoYXMgdGhlIHVwc2lkZSBvZiBkZWZpbmluZyBhIG5pY2UgYXJ0aWZhY3QgZW5jb2Rp bmcgZm9yIGJvdGggcmVtb3ZhYmxlIG1lZGlhIGFuZCBESENQLCBidXQgd2l0aCB0aGUgZG93bnNp ZGUgb2YgY29tcGxpY2F0aW5nIEROUyBtYXBwaW5ncy4mbmJzcDsgU2ltcGxlIGlzIHRoZSBzb2x1 dGlvbiBkZXNjcmliZWQNCiBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaC0wOCNzZWN0aW9uLTQuMiI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3VjaC0wOCNzZWN0aW9u LTQuMjwvYT4sIGJ1dCB3ZSBjb3VsZCBiaXRlIHRoZSBidWxsZXQgYW5kIGluc3RlYWQgKnJlcGxh Y2UqIHRoZSBmaXJzdCBmb3VyIGVudHJpZXMgbGlzdGVkIChob3N0bmFtZSAmIzQzOyBwb3J0ICYj NDM7IGFuY2hvciAmIzQzOyBzaWduYXR1cmUpIHdpdGggYSBzaW5nbGUgVFhUIHJlY29yZCBlbmNv ZGluZyB0aGUgZm91ciB2YWx1ZXMgaW50byBhIHBrY3MjNw0KIHN0cnVjdHVyZS4mbmJzcDsgVGhh dCBpcywgdGhlcmUgd291bGQgYmUgKm5vKiBTUlYgcmVjb3JkcywuJm5ic3A7IEFsdGVybmF0aXZl bHksIHdlIGNvdWxkIGFsbG93IGZvciByZWR1bmRhbnQgZGF0YSBpbiBTUlYgcmVjb3Jkcywgd2hp Y2ggd291bGQgYmUgbmljZSBmb3Igd2hlbiB0aGUgZGF0YSBpcyB1bnNpZ25lZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5UaG91Z2h0cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5LZW50 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+TmV0Y29uZiAm bHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4g Jmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwg TWF5IDExLCAyMDE2IGF0IDc6MjAgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldGNvbmZAaWV0 Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PltOZXRjb25mXSB6ZXJvdG91Y2gvMTM6IFNpZ25hdHVyZSBvdmVyIFlBTkcgZGF0YT88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29u Zi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdDtib3gtc2l6aW5nOiBib3JkZXItYm94Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMz MzMzIj5TbGlkZSAjMTEmbmJzcDtwcmVzZW50ZWQgZHVyaW5nIHRoZSBJRVRGIDk1IG1lZXRpbmcg c2FpZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBp bjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPj09 PT09U1RBUlQ9PT09PTxicj4NCkN1cnJlbnQgdGV4dCBzYXlzIHRoYXQgdGhlIHNpZ25hdHVyZSBp cyBvdmVyIHRoZSBkYXRhIGluIHdoYXRldmVyIGZvcm0gaXTigJlzIHByb3ZpZGVkIChYTUwgb3Ig SlNPTik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBp bjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPlRo aXMgd29ya3MgZ3JlYXQgZm9yIGFsbCBzb3VyY2VzIG9mIGJvb3RzdHJhcHBpbmcgZGF0YSBidXQs IGZvciB0aGUgYm9vdHN0cmFwIHNlcnZlciwgcmVxdWlyZXMgdGhhdCBib3RoIHRoZSBub3J0aGJv dW5kIGFwcGxpY2F0aW9uIGFuZCB0aGUgZGV2aWNlIGFjY2VzcyBzcGVjaWZpYyBVUkwgcmVzb3Vy Y2VzOjxicj4NCi9pZXRmLXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyOmRldmljZXMvZGV2aWNl PTEyMzQ1Ni9yZWRpcmVjdC1pbmZvcm1hdGlvbjxicj4NCi9pZXRmLXplcm90b3VjaC1ib290c3Ry YXAtc2VydmVyOmRldmljZXMvZGV2aWNlPTEyMzQ1Ni9ib290c3RyYXAtaW5mb3JtYXRpb248L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjtib3gtc2l6 aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPkJ1dCB0aGlzIGFw cHJvYWNoIGhhcyBpc3N1ZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVs MSBsZm8zO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlNlcnZlciBNVVNU IE5PVCBjaGFuZ2UgaXRzIGVuY29kaW5nIGluIGFueSB3YXkgYmV0d2VlbiB0aGUgdGltZSB0aGUg ZGF0YSB3YXMgc2F2ZWQgYW5kIHdoZW4gdGhlIGRldmljZSByZXRyaWV2ZXMgdGhlIGRhdGE8L3Nw YW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMz MzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMiBsZXZlbDEgbGZvMztib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7Ij5UaGVzZSB0d28gcmVzb3VyY2VzIGFyZSB1bmRlciBhIGNob2ljZSBub2RlLCBhbmQgdGhl IGRldmljZSBkb2VzbuKAmXQga25vdyB1cCBmcm9udCB3aGljaCB3aWxsIGJlIHByZXNlbnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMz MzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzM7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OyI+SXQgaXMgZGVzaXJhYmxlIGZvciBkZXZpY2UgdG8ganVzdCBmZXRjaCB0aGUgdG9wLWxl dmVsIOKAnGRldmljZeKAnSByZXNvdXJjZSwgdG8gZ2V0IGV2ZXJ5dGhpbmcgaW4gb25lIHJlcXVl c3Q8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjBpbjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMi Pk9wdGlvbnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm82O2Jv eC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPktlZXAgYXMgaXMgKGUuZy4sIGZv cmNlIGRldmljZSB0byB0cnkgYm90aCBVUkwgcmVzb3VyY2VzKSAvLyB1cCB0byAzIHJvdW5kIHRy aXBzIGluc3RlYWQgb2YganVzdCBvbmU8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDEgbGZvNjtib3gtc2l6 aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EZWZpbmUgYSBjYW5vbmljYWwgZm9ybWF0 IGZvciBYTUwgYW5kIEpTT04gZW5jb2RpbmdzIC8vIE5vdCBzdXJlIGlmIHRoaXMgaXMgZXZlbiBw b3NzaWJsZeKApjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm82O2JveC1zaXppbmc6IGJvcmRlci1i b3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDsiPkRlZmluZSBhbiBlbmNvZGluZy1pbmRlcGVuZGVudCBzaWduYXR1 cmUgYWxnb3JpdGhtICZuYnNwOyAmbmJzcDsgJm5ic3A7Ly8gdHJpY2t5IHRvIGRlZmluZSwgbm90 IGVhc3kgdG8gaW1wbGVtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzY7Ym94LXNpemluZzog Ym9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+RW5jb2RlIGJvdGggcmVzb3VyY2VzIGluIGEgbGVh ZiBoYXZpbmcgdHlwZSDigJxzdHJpbmfigJ0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gZXZlbiB0 aG91Z2ggaXTigJlzIFlBTkctZW5jb2RlZCBkYXRhPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5UaG91Z2h0cz88YnI+DQo9PT09PVNUT1A9PT09 PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2Jv eC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+SW4gdGhl IGRpc2N1c3Npb24gb24gdGhpcyBzbGlkZSwgSmVmZiBIYWFzIG5vdGVkIHRoYXQgUEtDUyM5IGlz IHBvcHVsYXIgaW4gdGhlIElFVEYgYW5kIHRoYXQgaGUgZmVsdCB0aGF0IGNhbm9uaWNhbGl6YXRp b24gbWlnaHQgYmUgYSByZXF1aXJlbWVudC4gQnV0IEtlbnQgbm90ZWQgdGhhdCBjYW5vbmljYWxp emF0aW9uDQogaXMgcHJhY3RpY2FsbHkgaW1wb3NzaWJsZSBnaXZlbiB0aGF0IFhNTC9KU09OIGhh cyBubyBndWFyYW50ZWVkIG9yZGVyaW5nIG9mIHRyZWUgbm9kZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3giPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPkkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhIGdvb2Qgc29s dXRpb24geWV0Li4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6 MGluO2JveC1zaXppbmc6IGJvcmRlci1ib3giPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjtib3gt c2l6aW5nOiBib3JkZXItYm94Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowaW47Ym94LXNpemluZzog Ym9yZGVyLWJveCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+S2VudDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjtib3gtc2l6aW5nOiBib3JkZXItYm94 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5EF4CAA84088445D83B52BFED8C24410junipernet_-- From nobody Wed Jul 6 17:14:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EB412B078 for ; Wed, 6 Jul 2016 17:14:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2grYip0hFyl for ; Wed, 6 Jul 2016 17:14:34 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D2C12B00B for ; Wed, 6 Jul 2016 17:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pcc6IbxU+Z/eB6JBvfi9FCX/ArLm2WIHgybpIRiAh8g=; b=Sa1QXWLFYYGMASqv/iPNOeGpKn7R3Td7N2mAC1UiDurbRUkoCi5Fs/DTjZjiYx7h3aBSFGMhMlRsBEXX0K3aKvoTD/hEkxXFvQMlD+k9wjhuD50avz/EU8QB24SvGtNQvGniJ13wzBjtG+RSkZKOr5HqqnkGE2xx4o1XpUBD1+c= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.528.16; Thu, 7 Jul 2016 00:14:32 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.022; Thu, 7 Jul 2016 00:14:32 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch/16: How to encode a chain of certs? Thread-Index: AQHR1+SJsFH9hA3wQUONhRfU42U5mA== Date: Thu, 7 Jul 2016 00:14:32 +0000 Message-ID: <5D798026-E4BC-4BB2-8939-D10892ED1282@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: bb387a61-4f7a-4703-ec2c-08d3a5fbabb1 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:EmZUMksjYo+5FEMDTfH9bFEhdlP4RrPxp3v0ZUVw+KjgmPvm9gdmu6oD77H2caVwXndq3SIC1K0d47ypgs+fnnJStbCIbN6N1OzpGRct8A2PE11wYmTbNPAWbOLmiGxt4MN+Ml9zirz9cubKSZyDQXQ8S+qnb9OU0x0n81N8ZjcT60QbnCmBrAQ00PdoXfyriIWrY/T39lPSzpsEgcRycH7k2/3QDAqOb0fISJnVfJuBeS1IlC6sq48X8SzsneWTCbk9VP8Co/9Fml2k5c59Hq05xkGF0scB/tBuYHAFi6nLUIJVJye4rBZdf2PDioi2eD5vMpDXXS+7ofzyt8dZ7A==; 5:gWul8BgLLn4d4951BwPx+r+c9qFSS0ZuFxZz8rPRKZ4SrBP/4x1tPFqQPiJIVFgC4UkZtF9WurTE6wU5AwhflsfbC9sj3kWpd6LQBVSUxC1TXO6rC3ffUxAdHseZUDKP3zqTOGLZrHbfITJQKxTbgw==; 24:/FXBc73SmRA7+mebzfO6ccoEUVtfYnsDSc17masoA2nzvU50BYCGBBe1Rap8EylHN8AtyQhmcGehOSQezEiBXrhkdw+fjq6s33N/gMTBrFE=; 7:708fmlNxU95PytaCNZanSvRrJzCTHmBBpi9kyp5elOHzkggm836qVCqiAWVTWaWCDHmhiqT+qtXNRfDjv/9QZx6UdlXZ9BZrKdT0P3PIMKk/cpUvJw3pAPG65URbj5wqbpM3kZjH0GT8CE03EU37+uAAvWMVkB9kCpwxTcJM/gsXVR5ZCqYWqTCs8jLUwYxzaLuKtqx9Ho2oojyrcQFssu78wFXEHw7jUfNCARzjFtGFsZZoqAHZXhmi7GTlnuDn x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(51444003)(31014005)(189002)(3280700002)(586003)(16236675004)(19300405004)(7846002)(450100001)(5640700001)(81156014)(87936001)(4001350100001)(54356999)(50986999)(19580395003)(7736002)(97736004)(5002640100001)(36756003)(8676002)(86362001)(8936002)(229853001)(2351001)(81166006)(83716003)(1730700003)(3846002)(102836003)(6116002)(92566002)(7906003)(99286002)(11100500001)(68736007)(19617315012)(2501003)(2900100001)(66066001)(19625215002)(106356001)(110136002)(107886002)(122556002)(3660700001)(83506001)(106116001)(101416001)(33656002)(189998001)(77096005)(82746002)(105586002)(15975445007)(2906002)(10400500002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5D798026E4BC4BB28939D10892ED1282junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 00:14:32.4750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452 Archived-At: Subject: [Netconf] zerotouch/16: How to encode a chain of certs? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 00:14:37 -0000 --_000_5D798026E4BC4BB28939D10892ED1282junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpOZXcgaXNzdWU6IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNz dWVzLzE2DQoNClRoZSBkcmFmdCBjdXJyZW50bHkgc3RhdGVzIHRoYXQgdGhlIG93bmVyLWNlcnRp ZmljYXRlIGlzIGp1c3QgYSBzaW5nbGUgY2VydGlmaWNhdGUsIGJ1dCB0aGUgb3duZXIgY2VydGlm aWNhdGUgYWN0dWFsbHkgbmVlZHMgdG8gYmUgcHJlc2VudGVkIGFsb25nIHdpdGggaXRzIGNoYWlu IG9mIGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMgbGVhZGluZyB1cCB0byB0aGUgdHJ1c3QgYW5j aG9yIGNlcnRpZmljYXRlIGtub3duIHRoZSB0byBtYW51ZmFjdHVyZXIncyBkZXZpY2VzLiAgSGVy ZSBhcmUgc29tZSBvcHRpb25zOg0KDQogIDEuIHVzZSBhbiBvcmRlcmVkLWJ5LXVzZXIgbGVhZi1s aXN0IG9mIHRoZSBYLjUwOXYzIHN0cnVjdHVyZXMgZW5jb2RlZCB1c2luZyBERVINCiAyLiB1c2Ug YSBQRU0gZmlsZSAoc3RyaW5nKSB0aGF0IGNhbiBlbmNvZGUgbXVsdGlwbGUgY2VydGlmaWNhdGVz DQogIDMuIHVzZSBhIFBLQ1MjMTIgc3RydWN0dXJlIGZyb20gUkZDIDcyOTIgdG8gZW5jb2RlIGEg YnVuZGxlIG9mIGNlcnRzDQoNCk5vdGVzOg0KICAtIE9wdGlvbiAjMSBpcyB3aGF0IGlzIGN1cnJl bnRseSB1c2VkIGluIHRoZSBzeXN0ZW0ta2V5Y2hhaW4gbW9kZWwsIGJ1dCBJIHRoaW5rIHRoYXQg aXTigJlzIGNsdW5reSBhbmQgc2hvdWxkIGJlIHJlcGxhY2VkLg0KICAtIE9wZW5TU0wgY2FuIGNv bnZlcnQgYmV0d2VlbiAjMiBhbmQgIzMgd2VsbCBlbm91Z2guDQoNClRob3VnaHRzPw0KDQpUaGFu a3MsDQpLZW50DQoNCg== --_000_5D798026E4BC4BB28939D10892ED1282junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TmV3IGlzc3VlOiA8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xNiI+DQpodHRwczovL2dpdGh1 Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xNjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBkcmFmdCBjdXJyZW50bHkgc3RhdGVzIHRo YXQgdGhlIG93bmVyLWNlcnRpZmljYXRlIGlzIGp1c3QgYSBzaW5nbGUgY2VydGlmaWNhdGUsIGJ1 dCB0aGUgb3duZXIgY2VydGlmaWNhdGUgYWN0dWFsbHkgbmVlZHMgdG8gYmUgcHJlc2VudGVkIGFs b25nIHdpdGggaXRzIGNoYWluIG9mIGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMgbGVhZGluZyB1 cCB0bw0KIHRoZSB0cnVzdCBhbmNob3IgY2VydGlmaWNhdGUga25vd24gdGhlIHRvIG1hbnVmYWN0 dXJlcidzIGRldmljZXMuJm5ic3A7IEhlcmUgYXJlIHNvbWUgb3B0aW9uczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAxLiB1c2UgYW4gb3JkZXJlZC1i eS11c2VyIGxlYWYtbGlzdCBvZiB0aGUgWC41MDl2MyBzdHJ1Y3R1cmVzIGVuY29kZWQgdXNpbmcg REVSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzIuIHVzZSBhIFBFTSBmaWxlIChzdHJpbmcpIHRo YXQgY2FuIGVuY29kZSBtdWx0aXBsZSBjZXJ0aWZpY2F0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7IDMuIHVzZSBhIFBLQ1MjMTIgc3RydWN0dXJlIGZyb20gUkZDIDcyOTIgdG8gZW5jb2RlIGEg YnVuZGxlIG9mIGNlcnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5Ob3RlczogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOy0gT3B0aW9uICMxIGlzIHdo YXQgaXMgY3VycmVudGx5IHVzZWQgaW4gdGhlIHN5c3RlbS1rZXljaGFpbiBtb2RlbCwgYnV0IEkg dGhpbmsgdGhhdCBpdOKAmXMgY2x1bmt5IGFuZCBzaG91bGQgYmUgcmVwbGFjZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOyAtIE9wZW5TU0wgY2FuIGNvbnZlcnQgYmV0d2VlbiAjMiBhbmQgIzMg d2VsbCBlbm91Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aG91Z2h0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+S2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D798026E4BC4BB28939D10892ED1282junipernet_-- From nobody Wed Jul 6 18:16:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6B012B044 for ; Wed, 6 Jul 2016 18:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLIcemlU_lvJ for ; Wed, 6 Jul 2016 18:16:37 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0116.outbound.protection.outlook.com [104.47.36.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B1C12B00D for ; Wed, 6 Jul 2016 18:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=68SbufMCSIWuC1V6Ok78gI8edfVeELtCuUvvtuTlq2M=; b=ACbrPgXf+Am0kTxcHah6gPnVNa9zQ6dY0pseAXvigKlQ6qZ/2/ASllkNe8/Ffc+7foJkV4srNGaDZzBOxPxYfEmHQxYJDRH9uHsxH922KegZGEksB0AFCL24fBB5EMwOE4Rry03H2Od0EopuhQPAZ4mgVe0/xwv1nhq2Jc75LK8= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Thu, 7 Jul 2016 01:16:34 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.022; Thu, 7 Jul 2016 01:16:34 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch/17: How to verify boot-image integrity? Thread-Index: AQHR1+0zZ+YKXSlsgEa0qw/6IXOQEQ== Date: Thu, 7 Jul 2016 01:16:34 +0000 Message-ID: <8C077DAC-4A77-4467-9B2E-E04F226DBBC1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: b7f73079-6b33-401e-63f9-08d3a604563d x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:cNWqC+GjfDl3Om3JubFBzCGQCmkvxnV10HZxt0E4q9BU2y8JqT8IrC1ms+SL+ijBYh7c6jZIb387TqeJlxhBocfIFmIhWIuNtyPa/uWVKjWnt57WWMi4v1rtjrhdqkR1/orH3j6Z+L3bICg+Hme93ePyFfI0vIKRz2t1eyF1urqynQ6gmxdHl5RlAapgSWNNs3PtvJTlI2fLYkAn4ZQzfl2k5WVdIXy7cCMw+WbnIJVvlPmWnWyH0PwMoiWX8CYCQoQPafYGuT0hs7fmtdV5zDxIccYiQvfXSZo8M44+G6e8x0NEQOXQFryjjurIPVHa9rdi4bAfLlNQI+b8U0L1Aw==; 5:6gJECpVQcaBvSb4tGwpU6MoCFmZlD36XH/kDAKgXus7kQrzxL2i0Ue9EraJmpPL5uOyXhToNqksOAZLnNiO1R6elfZ9R2w/hypO6n2OxuaE6/YS+x9Ye4HmHF1r+Rg52+uvqc+ioSFMPxqIpkOhMfQ==; 24:syIzWT8XVLkw2AWq1erHus/bpNgv5tOyceTvha8rxQnVrEmFmYOFu6SY4iXepQCY6T/h5mhSCYuZFTt8BfrQ853JMA3litMR59VMafXCYRk=; 7:/Pb+aiu48PTKKvk/VPa6aPYdP8kKSTibuENAy175SAUmVDNfRtmqDUdm1hsmv3zikz6//sCht43FO3GP/I4X/wVhz3Sml19KL3gOKLKoWjg9BEuMdHVF0LM9RDaUSsnZvRWWthadrHQhqR4W6Vv83OyinvzCf4vhbjfyH3IEZJaFmA41gGthDxOn+39cFRT02ZtENexMZPs/9j45HpkElBkyjOFSAbll/0oImjxmUan97LrRnGcZr6TsjykUlRzk x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(31014005)(189002)(5002640100001)(586003)(2420400007)(10710500007)(3660700001)(66066001)(106356001)(36756003)(7110500001)(16236675004)(11100500001)(5640700001)(189998001)(8936002)(105586002)(8676002)(450100001)(3280700002)(106116001)(2906002)(107886002)(110136002)(3846002)(50986999)(4001350100001)(19580395003)(54356999)(81156014)(2900100001)(82746002)(7736002)(1730700003)(15975445007)(77096005)(81166006)(229853001)(86362001)(2351001)(19300405004)(7906003)(122556002)(101416001)(6116002)(102836003)(15650500001)(83716003)(2501003)(99286002)(33656002)(92566002)(19617315012)(19625215002)(83506001)(68736007)(10400500002)(97736004)(7846002)(87936001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8C077DAC4A7744679B2EE04F226DBBC1junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 01:16:34.5385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: [Netconf] zerotouch/17: How to verify boot-image integrity? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:16:41 -0000 --_000_8C077DAC4A7744679B2EE04F226DBBC1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmV3IGlzc3VlOiBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vl cy8xNw0KDQpUaGUgY3VycmVudCBkcmFmdCBoYXJkY29kZXMgdGhlIHVzZSBvZiBib3RoIHRoZSBN RDUgYW5kIFNIQTEgaGFzaCBhbGdvcml0aG1zIGZvciB0aGUgcHVycG9zZSBvZiBlbmFibGluZyBh IGRldmljZSB0byB2ZXJpZnkgYSBkb3dubG9hZGVkIGJvb3QtaW1hZ2UsIHRoYXQgbWF5IG5vdCBo YXZlIGFuIGVtYmVkZGVkIHNpZ25hdHVyZS4NCg0KICAgICAgICAgICAgICAgICAgKy0tcm8gYm9v dC1pbWFnZQ0KICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbW9kdWxlcw0KICAgICAgICAgICAg ICAgICAgICAgfCAgKy0tcm8gbW9kdWxlKg0KICAgICAgICAgICAgICAgICAgICAgfCAgICAgKy0t cm8gbmFtZT8gICAgICAgeWFuZzp5YW5nLWlkZW50aWZpZXINCiAgICAgICAgICAgICAgICAgICAg IHwgICAgICstLXJvIHJldmlzaW9uPyAgIHN0cmluZw0KICAgICAgICAgICAgICAgICAgICAgKy0t cm8gbmFtZSAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICstLXJvIG1kNSAgICAg ICAgc3RyaW5nDQogICAgICAgICAgICAgICAgICAgICArLS1ybyBzaGExICAgICAgIHN0cmluZw0K ICAgICAgICAgICAgICAgICAgICAgKy0tcm8gdXJpKiAgICAgICBpbmV0OnVyaQ0KDQpCdXQgYSBy ZWNvbW1lbmRhdGlvbiBjYW1lIChhdHRyaWJ1dGlvbj8pIHRvIHRyeSB0byB1c2UgYSBkaWdlc3Qg Zm9ybWF0IG1vcmUgZ2VuZXJpYyBhbmQgbGVzcyBvYnNvbGV0ZS4NCg0KSGVyZSBhcmUgc29tZSBv cHRpb25zOg0KDQogIDApIGRvIG5vdGhpbmcsIGtlZXAgYXMgbWQ1IGFuZCBzaGFsbA0KICAxKSBy ZXBsYWNlIGJvdGggd2l0aCBzaGEyNTYgLy8gc3RpbGwgaGFyZGNvZGVkLCBidXQgY3VycmVudA0K ICAyKSBkZWZpbmUgYW4gaWRlbnRpdHkgYmFzZSB0eXBlICgiZGlnZXN0LWFsZ29yaXRobSIpIGFu ZCBzb21lIGRlcml2ZWQgdHlwZXMgZm9yIHBvcHVsYXIgZGdzdCBsYWdzDQoNCkFueSBvdGhlciBp ZGVhcz8NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg== --_000_8C077DAC4A7744679B2EE04F226DBBC1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OZXcgaXNz dWU6IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNz dWVzLzE3Ij4NCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNzdWVz LzE3PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGN1 cnJlbnQgZHJhZnQgaGFyZGNvZGVzIHRoZSB1c2Ugb2YgYm90aCB0aGUgTUQ1IGFuZCBTSEExIGhh c2ggYWxnb3JpdGhtcyBmb3IgdGhlIHB1cnBvc2Ugb2YgZW5hYmxpbmcgYSBkZXZpY2UgdG8gdmVy aWZ5IGEgZG93bmxvYWRlZCBib290LWltYWdlLCB0aGF0IG1heSBub3QgaGF2ZSBhbiBlbWJlZGRl ZCBzaWduYXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIGJv b3QtaW1hZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBtb2R1bGVzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ybyBtb2R1bGUqPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBuYW1lPyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt5YW5nOnlhbmctaWRlbnRpZmllcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t cm8gcmV2aXNpb24/Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstLXJvIG5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gbWQ1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstLXJvIHNoYTEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gdXJpKiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpbmV0OnVyaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+QnV0IGEgcmVjb21tZW5kYXRpb24gY2FtZSAoYXR0cmlidXRpb24/KSB0 byB0cnkgdG8gdXNlIGEgZGlnZXN0IGZvcm1hdCBtb3JlIGdlbmVyaWMgYW5kIGxlc3Mgb2Jzb2xl dGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlcmUgYXJl IHNvbWUgb3B0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOyAwKSBkbyBub3RoaW5nLCBrZWVwIGFzIG1kNSBhbmQgc2hhbGw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7IDEpIHJlcGxhY2UgYm90aCB3aXRoIHNoYTI1NiAvLyBzdGlsbCBoYXJkY29k ZWQsIGJ1dCBjdXJyZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAyKSBkZWZpbmUgYW4gaWRl bnRpdHkgYmFzZSB0eXBlICgmcXVvdDtkaWdlc3QtYWxnb3JpdGhtJnF1b3Q7KSBhbmQgc29tZSBk ZXJpdmVkIHR5cGVzIGZvciBwb3B1bGFyIGRnc3QgbGFnczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+QW55IG90aGVyIGlkZWFzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8C077DAC4A7744679B2EE04F226DBBC1junipernet_-- From nobody Wed Jul 6 18:23:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3412B054 for ; Wed, 6 Jul 2016 18:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqRNsQMMJMUY for ; Wed, 6 Jul 2016 18:23:07 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0106.outbound.protection.outlook.com [104.47.41.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D6C12B032 for ; Wed, 6 Jul 2016 18:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o3ekpWtVMoDBDFDt/Wytj5VwaNYFKgPb5EeulMJ1r0o=; b=N3EqTw1/6JIPNjUhaRrB47EeqSGNRGL6bId2ym/voNZHl+HnpK55r/ngDMBZ4H2uLHm7ZNkt6lvLZIu0Fyek0HG/pc/E5gh0XIfQe+QKRCOf2xA6McBVL1HHxoMRbsIUrK3t1syHcdeJxtwmHrJ2PCPlROdRSdlOkB4fNFBjgpg= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Thu, 7 Jul 2016 01:23:05 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.022; Thu, 7 Jul 2016 01:23:05 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch/15: Enhanced script support Thread-Index: AQHR1+4c7FxNR59PjU6DiewErpapTw== Date: Thu, 7 Jul 2016 01:23:05 +0000 Message-ID: <42DA2449-AE04-44FD-863A-55569D6A6F28@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 833814ce-bc55-4b45-718a-08d3a6053f39 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:Q7L7f1TWAj/ABqynXDa7ejZpC+ROtKKhoIIAdcghiCJA6QpjDcKnGgPL3tJ1l4edO+M4EffdVyTJncMZ5KjeQ8XoU0z16qgjHnfnBpBjaCpiLlgAcOySDZohsrcR7+FOeMpO0YrK+2ZlEpBmZaz9+ZEI7nl6Vg47mMtJFq0kHvrvUz71+13MAokk6ZnhynyiD6ySsUdY4EqQq9MGgV8GjiPgF1qRx+bhPmnBD7SRCo034If16daKFlQIG464uRM29sRvcbEeTvgwtvBXTpSJcshIHINAbY1s8vr3PWWoz/ylE2tFZrZLJ8uso1W8Mktk6JJ3y4UXd+n6K9P9whnJGA==; 5:4MAOiHWv5UqXTdtP85bDdom1EoykLn0nBzGY+KriLyEuNTiNd+QyI69atYOhGJ68idGBEDLhTYgVXPtHNi5yhAhh/iMNL8i7OpktjmauN+kpmqX08y/RaiGGGfRV3CkGlKl/HkfXtb+mGyHKWJSAHA==; 24:pg8ksSBXKZ0pXfEIdYXLMfvsvKGtIY3Xih/z+XRQh1m52yghWKNns8GOpLKmYgg66zbw+WHHeUeERQERpc7p35oIiS1qoaCuGLZWD/7ONZM=; 7:gk0utznobCP3IRXrinPdZ2+OKDYloLlH2cOuCPxA3wPavt2e3WwPaI+cAOn0LDyTTUUysIAjAE/JOQwnmVOR83jI+Ff9lcOL3HvQ3iUXLlCZFgL2ochLQqTjrvZo7kiOVmvv16fQVAf0IGeV4XVyoaPQ271y+EZzjo7FWDLtF4sMV/11/KQc00T6//T0ZUVgadpvPnfam/my/XMt2CMyI1lM5qJsd+FlvqmvyJH9yc/BjBeHRsZ5inC/vwkEd7Kp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(478694002)(24454002)(81166006)(19580405001)(77096005)(15975445007)(1730700003)(2351001)(86362001)(54356999)(81156014)(4001350100001)(50986999)(305945005)(19580395003)(7736002)(2900100001)(82746002)(68736007)(10400500002)(97736004)(33656002)(92566002)(99286002)(83506001)(87936001)(3846002)(7846002)(101416001)(122556002)(83716003)(2501003)(102836003)(6116002)(110136002)(5002640100001)(586003)(8936002)(5640700001)(189998001)(11100500001)(106116001)(3280700002)(107886002)(2906002)(105586002)(8676002)(450100001)(3660700001)(66066001)(106356001)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5B80E146BFD8F645892F2F54356A1DA4@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 01:23:05.4057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: Re: [Netconf] zerotouch/15: Enhanced script support X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:23:10 -0000 DQpTbyBteSB0aG91Z2h0cyBvbiB0aGlzIGFyZSB0byBzdXBwb3J0IGFsc28gYSDigJxwcmUtY29u ZmlndXJhdGlvbi1zY3JpcHTigJ0sIGJ1dCB0byBub3Qgd29ycnkgYWJvdXQgcGFyYW1ldGVycyBh cyB0aGUgYW55IHN1Y2ggZGV2aWNlLXNwZWNpZmljIHBhcmFtZXRlcnMgY2FuIGJlIGVuY29kZWQg aW50byB0aGUgc2NyaXB0IGl0c2VsZi4gICBPZiBjb3Vyc2UsIEnigJltIGFzc3VtaW5nIHRoYXQg dGhlIHNjcmlwdCBpcyByZWFsbHkgYXMgc2NyaXB0LCBhbmQgbm90IGEgY29tcGlsZWQgZXhlY3V0 YWJsZS4gICBJZiB3ZSB3YW50IHRvIHN1cHBvcnQgY29tcGlsZWQgZXhlY3V0YWJsZXMsIHRoZW4g cGFyYW1ldGVycyBtaWdodCBiZSBnb29kLiAgQW55IGNvbW1lbnRzPyAgLSBzaG91bGQgd2UgdHJ5 IHRvIHN1cHBvcnQgY29tcGlsZWQgZXhlY3V0YWJsZXM/DQoNCktlbnQNCg0KDQoNCk9uIDYvMjkv MTYsIDc6MzYgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6 DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNzdWVzLzE1DQoN ClRoZSBjdXJyZW50IGRyYWZ0IGFsbG93cyBmb3IgYSBzaW5nbGUgc2NyaXB0IHRoYXQgdGFrZXMg bm8gY29tbWFuZC1saW5lIHBhcmFtZXRlcnMuIE9uLWdvaW5nIGltcGxlbWVudGF0aW9uIGRpc2N1 c3Npb25zIHN1Z2dlc3QgdGhhdDoNCg0KMSkgdGhlcmUgc2hvdWxkIGJlIHN1cHBvcnQgdG8gcnVu IGEgc2NyaXB0IGJvdGggYmVmb3JlIGFuZCBhZnRlciB0aGUgY29uZmlndXJhdGlvbiBpcyBjb21t aXR0ZWQuDQogICAgICAgLSB0aGlzIG1lYW5zIHRoYXQgd2UnZCBuZWVkIGJvdGggInByZS1zY3Jp cHQiIGFuZCAicG9zdC1zY3JpcHQiIGxlYXZlcw0KICAgICAgIC0gZm9yIGluc3RhbmNlOg0KDQpP TEQ6DQoNCiAgICAgICAgICAgICAgICAgKy0tcm8gYm9vdHN0cmFwLWluZm9ybWF0aW9uDQogICAg ICAgICAgICAgICAgICAgICstLXJvIGJvb3QtaW1hZ2UNCiAgICAgICAgICAgICAgICAgICAgfCAg Ky0tLi4uDQogICAgICAgICAgICAgICAgICAgICstLXJvIGNvbmZpZ3VyYXRpb24NCiAgICAgICAg ICAgICAgICAgICAgKy0tcm8gc2NyaXB0PyAgICAgICAgICBzdHJpbmcNCk5FVzoNCg0KICAgICAg ICAgICAgICAgICArLS1ybyBib290c3RyYXAtaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgICAg ICAgKy0tcm8gYm9vdC1pbWFnZQ0KICAgICAgICAgICAgICAgICAgICB8ICArLS0uLi4NCiAgICAg ICAgICAgICAgICAgICAgKy0tcm8gcHJlLWNvbmZpZ3VyYXRpb24tc2NyaXB0PyAgICAgICAgICBz dHJpbmcNCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gY29uZmlndXJhdGlvbg0KICAgICAgICAg ICAgICAgICAgICArLS1ybyBwb3N0LWNvbmZpZ3VyYXRpb24tc2NyaXB0PyAgICAgICAgIFN0cmlu Zw0KDQoNCg0KMikgdGhlcmUgc2hvdWxkIGJlIHN1cHBvcnQgZm9yIHBhc3NpbmcgY29tbWFuZCBs aW5lIHBhcmFtZXRlcnMsIHNvIHRoYXQgdGhlIHNhbWUgc2NyaXB0IGNhbiBiZSB1c2VkIG9uIG1h bnkgZGV2aWNlcy4gVGhpcyBpcyBlc3NlbnRpYWxseSBzaGlmdGluZyB3aGVyZSB2YXJpYWJsZSBi aW5kaW5ncyBvY2N1ciAtIGVpdGhlciB0aGUgTk1TIHJlbmRlcnMgYSBkZXZpY2Utc3BlY2lmaWMg c2NyaXB0IChpbmNvcnBvcmF0aW5nIGRldmljZS1zcGVjaWZpYyB2YWx1ZXMpLCBvciB0aGUgZGV2 aWNlIHJlbmRlcnMgaXQgKHVzaW5nIGNvbW1hbmQtbGluZSB2YXJpYWJsZXMgdG8ga25vdyBob3cg dG8gZG8gdGhlIHN1YnN0aXR1dGlvbnMpLiBUaGUgbGF0dGVyIGlzIGhhcmRlciBvbiBkZXZpY2Vz LCBidXQgdGhlIGZvcm1lciBtYXkgZW5hYmxlIGJldHRlciBzY2FsYWJpbGl0eS4gVG8gaW1wbGVt ZW50IHRoaXMsIHdlIG1pZ2h0IGhhdmUgc29tZXRoaW5nIGxpa2U6DQoNCk5FVzogLy8gYWRkaW5n IG9udG8gdGhlIGFib3ZlIGV4YW1wbGUNCg0KICAgICAgICAgICAgICAgICArLS1ybyBib290c3Ry YXAtaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gYm9vdC1pbWFnZQ0KICAg ICAgICAgICAgICAgICAgICB8ICArLS0uLi4NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gcHJl LWNvbmZpZ3VyYXRpb24tc2NyaXB0DQogICAgICAgICAgICAgICAgICAgIHwgICstLSBzY3JpcHQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQogICAgICAgICAg ICAgICAgICAgIHwgICstLSBwYXJhbWV0ZXJzICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz dHJpbmcNCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gY29uZmlndXJhdGlvbg0KICAgICAgICAg ICAgICAgICAgICArLS1ybyBwb3N0LWNvbmZpZ3VyYXRpb24tc2NyaXB0DQogICAgICAgICAgICAg ICAgICAgICAgICstLSBzY3JpcHQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc3RyaW5nDQogICAgICAgICAgICAgICAgICAgICAgICstLSBwYXJhbWV0ZXJzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCg0KDQpBbnkgdGhvdWdodHMgb24gdGhpcyBvbmU/ DQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0K From nobody Wed Jul 6 18:50:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195D312D520 for ; Wed, 6 Jul 2016 18:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywMfT53mb9De for ; Wed, 6 Jul 2016 18:50:38 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0100.outbound.protection.outlook.com [104.47.40.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2E212D507 for ; Wed, 6 Jul 2016 18:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vwnTepy8cnNQbmI1s2ciTktXOQ9l3Y/RjHubJTlKFdc=; b=d7sYw4pJ1MGZdZSrGvVkF9Ui+uQZ2OgXU1IhGC8IBGjdQbpcfywwGOxOu0KXQ/10cQmEfDejyQtJnylMQWf00cFLJwH4XtsRxZ+PQxbp8Jqjc7RTyIKvPIwIxn2yxUA+odOKsyInczFAxs7/gt1EqJAm7GPP9QZN3HdVmao3pnk= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Thu, 7 Jul 2016 01:50:36 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.022; Thu, 7 Jul 2016 01:50:36 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch/12: How to commit config? Merge/replace? Thread-Index: AQHR0lkNTjORHFXcL06wK5dz8frwDKAL/CeA Date: Thu, 7 Jul 2016 01:50:36 +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/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 174afdad-5da0-44a6-225e-08d3a6091734 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:XNPXQNCC3rekBoiNufPjZV4WghiJoBb5yKL53HqiCTat9DLBdFmZgDZ8dyKhG0H+E9M/nVj9hDWA+V+kD5nrcUmJ8zGP4w6tPu8jDi52CDjWdxq1hemin9DwSgPFKaUNlzc2KRHBKADlokf3ZXKwOvToFn/oi7u+tGxSiDOFCDerQnzYJ228jHh7ChT/gq0Qhbwq20DJzB5SUlvNv37UOsCsBS0UdKfrGpPqhLgJ3T6/O4Bq+LQRc6DL1imUSKJ+NUm1uy4rwz6D7oWMXGhNIQn8Rb1UGpeKUSEDJCKcGsudsMg7eSuK6EeqBQDWxmSXif1b6Ahr1tzEJE0aOmyYZQ==; 5:YS6MQJJqDIY8tLP+EjI/zSuoRtIPaYuq8X6HzdVaWmPgdPLSheWnoju6lzAwVGcaueAAaR1CD/Zoq/dAK1p78C0AD2HNUS0Mc39lJhcc6sMljIY1TPJw+sD2yvzPnavpd2nqg53iXHgGhRwjKdz+rA==; 24:OMg2iy506VQHgpM7kKcY6SclXbWoswzFmZAlXDWsfmPZxPLLbxphHbyhwJCZWwvakrO3dUSygpbhYrzB7VHP/+8mzcYjjHwEynFkJlrnq8A=; 7:Wcfr2nZA9UnP5bIbX3KfUAqsA9obzajZBJC2Nf1yMHnpDb1pqqoxNbkxiJz89B2zxu7GuxMN9nlCaAKzE3PQihh9j9lkP0PLck5oCytWNRKDbFsEsHABrp/i3j1Mw7q+e4j5TzYoyNxHofq7Z3TUxr9XeFdn/U5PDGP8sVCNhp/0Nj9iGdDGRNOMGV9CtHBLmAVQMVbYARu+e1b2bhS6GP3VsoirIEDq2WURi1M8u0d64AKazj+PycaFvTfyTfh6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(51444003)(377454003)(189002)(5002640100001)(586003)(3660700001)(66066001)(106356001)(110136002)(36756003)(16236675004)(11100500001)(5640700001)(189998001)(8936002)(105586002)(8676002)(450100001)(3280700002)(106116001)(2906002)(107886002)(50986999)(4001350100001)(19580395003)(54356999)(81156014)(2900100001)(82746002)(7736002)(1730700003)(15975445007)(77096005)(81166006)(19580405001)(86362001)(2351001)(19300405004)(122556002)(101416001)(6116002)(102836003)(83716003)(2501003)(99286002)(33656002)(92566002)(2950100001)(19625215002)(83506001)(68736007)(10400500002)(97736004)(76176999)(7846002)(87936001)(3846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B6D31AF243F945908D8854E3248C8E68junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2016 01:50:36.1979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:50:41 -0000 --_000_B6D31AF243F945908D8854E3248C8E68junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpTbyBJ4oCZdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBsZWFmIC0gYW55IHRob3VnaHRzPw0KDQog ICAgICAgICAgbGVhZiBjb25maWctaGFuZGxpbmcgew0KICAgICAgICAgICAgdHlwZSBlbnVtZXJh dGlvbiB7DQogICAgICAgICAgICAgIGVudW0gbWVyZ2Ugew0KICAgICAgICAgICAgICAgIGRlc2Ny aXB0aW9uDQogICAgICAgICAgICAgICAgICJNZXJnZSBjb25maWd1cmF0aW9uIGludG8gZXhpc3Rp bmcgcnVubmluZyBjb25maWd1cmF0aW9uLiI7DQogICAgICAgICAgICAgIH0NCiAgICAgICAgICAg ICAgZW51bSByZXBsYWNlIHsNCiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAg ICAgICAgICAgIlJlcGxhY2UgZXhpc3RpbmcgcnVubmluZyBjb25maWd1cmF0aW9uIHdpdGggcGFz c2VkDQogICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbi4iOw0KICAgICAgICAgICAgICB9 DQogICAgICAgICAgICAgIGVudW0gZWRpdC1jb25maWcgew0KICAgICAgICAgICAgICAgIGRlc2Ny aXB0aW9uDQogICAgICAgICAgICAgICAgICAiUHJvY2VzcyBjb25maWd1cmF0aW9uIGFzIGFuIDxl ZGl0LWNvbmZpZz4gZG9jdW1lbnQuIjsNCiAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICBl bnVtIHlhbmctcGF0Y2ggew0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAg ICAgICAgICAiUHJvY2VzcyBjb25maWd1cmF0aW9uIGFzIGEgWUFORyBQYXRjaCBkb2N1bWVudC4i Ow0KICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KDQpJIHdpc2gg ZWRpdC1jb25maWcgYW5kIHlhbmctcGF0Y2ggY291bGQgYmUgb3B0aW9ucy9mZWF0dXJlcywgYnV0 IHRoaXMgZG9lc27igJl0IHJlZHVjZSB0aGUgbnVtYmVyIG9mIGZvcm1hdHMgdGhhdCBkZXZpY2Vz IHdvdWxkIG5lZWQgdG8gc3VwcG9ydCwgYXMgbGltaXRpbmcgd2hhdCBhIHNwZWNpZmljIGJvb3Rz dHJhcC1zZXJ2ZXJzIHN1cHBvcnRzIGRvZXNu4oCZdCBsaW1pdCB3aGF0IG90aGVyIGJvb3RzdHJh cC1zZXJ2ZXJzIG1pZ2h0IHN1cHBvcnQuLi4NCg0KS2VudA0KDQoNCkZyb206IE5ldGNvbmYgPG5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrd2F0c2Vu QGp1bmlwZXIubmV0Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IGF0IDY6NTMgUE0N ClRvOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W05ldGNvbmZdIHplcm90b3VjaC8xMjogSG93IHRvIGNvbW1pdCBjb25maWc/IE1lcmdlL3JlcGxh Y2U/DQoNCg0KVHJ5aW5nIHRvIG1vdmUgdGhpcyBkaXNjdXNzaW9uIGZvcndhcmQuDQoNCknigJlt IHN0aWxsIHByZWZlciAoYikgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBiZWxvdywgYnV0IGl0IG1h eSBiZSBwb3NzaWJsZSB0byBkbyBzb21ldGhpbmcgaW4gYmV0d2VlbiAoYikgYW5kIChjKS4gIElu IHBhcnRpY3VsYXIsIGEgdG9wLWxldmVsIGZsYWcgY291bGQgYWxsb3cgZm9yIGVkaXQtY29uZmln IGFuZCB5YW5nLXBhdGNoIG9wdGlvbnMgYWxzby4NCg0KT0xEOg0KICAgICAgICAgICAgICArLS06 KGJvb3RzdHJhcC1pbmZvcm1hdGlvbikNCiAgICAgICAgICAgICAgICAgKy0tcm8gYm9vdHN0cmFw LWluZm9ybWF0aW9uDQogICAgICAgICAgICAgICAgICAgICstLXJvIGJvb3QtaW1hZ2UNCiAgICAg ICAgICAgICAgICAgICAgfCAgLi4uDQogICAgICAgICAgICAgICAgICAgICstLXJvIGNvbmZpZ3Vy YXRpb24NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gc2NyaXB0PyAgICAgICAgICBzdHJpbmcN Cg0KTkVXOg0KICAgICAgICAgICAgICArLS06KGJvb3RzdHJhcC1pbmZvcm1hdGlvbikNCiAgICAg ICAgICAgICAgICAgKy0tcm8gYm9vdHN0cmFwLWluZm9ybWF0aW9uDQogICAgICAgICAgICAgICAg ICAgICstLXJvIGJvb3QtaW1hZ2UNCiAgICAgICAgICAgICAgICAgICAgfCAgLi4uDQogICAgICAg ICAgICAgICAgICAgICstLXJvIGNvbmZpZy1oYW5kbGluZyAgZW51bSB7cmVwbGFjZSwgbWVyZ2Us IGVkaXQtY29uZmlnLCB5YW5nLXBhdGNofQ0KICAgICAgICAgICAgICAgICAgICArLS1ybyBjb25m aWd1cmF0aW9uDQogICAgICAgICAgICAgICAgICAgKy0tcm8gc2NyaXB0PyAgICAgICAgICBzdHJp bmcNCg0KVGhvdWdodHM/ICAtIGlzIGl0IHdvcnRoIGl0Pw0KDQpUaGFua3MsDQpLZW50DQoNCg0K RnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2Vu dCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQpEYXRlOiBXZWRuZXNkYXksIE1heSAxMSwg MjAxNiBhdCA3OjAzIFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3Jn Pg0KU3ViamVjdDogW05ldGNvbmZdIHplcm90b3VjaC8xMjogSG93IHRvIGNvbW1pdCBjb25maWc/ IE1lcmdlL3JlcGxhY2U/DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91 Y2gvaXNzdWVzLzEyDQoNCg0KU2xpZGUgMTAgZnJvbSB0aGUgemVybyB0b3VjaCBwcmVzbyBAIDk1 IGhhZDoNCg0KICBPcHRpb25zOg0KQS4gSGFyZGNvZGUg4oCdcmVwbGFjZeKAnSAgICAgICAgICAg ICAgICAgICAgICAgIC8vIGFsd2F5cyB3b3JrcywgYnV0IGxhcmdlIGluIHNpemUNCkIuIFVzZSBh IHRvcC1sZXZlbCBmbGFnICAgICAgICAgICAgICAgICAgICAgICAgIC8vIGxldCBkZXBsb3ltZW50 cyBkZWNpZGUNCkMuIFVzZSBlZGl0LWNvbmZpZyBvciB5YW5nLXBhdGNoPyAgICAgLy8gaXMgdGhp cyBtdWNoIGdyYW51bGFyaXR5IG5lZWRlZD8NCg0KVGhlIG1pbnV0ZXMgbm90ZSB0aGF0IFJpY2sg VGF5bG9yIHByZWZlcnMgdGhlIGxhc3Qgb3B0aW9uLCBzdGF0aW5nIHRoYXQgdGhlIGNvbmZpZ3Vy YXRpb24gY2FuIGJlIGJpZy4NCg0KQnV0IGxldCdzIGNvbnNpZGVyIG9wdGlvbiAoYikgaW4gdGhl IGNvbnRleHQgb2YgdGhlIGNvbmZpZyBiZWluZyBiaWcuICAgSWYgdGhlIHRvcC1sZXZlbCBmbGFn IGlzICdtZXJnZScgYW5kIHRoZSBjb25maWcgaXMgaHVnZSwgdGhlbiBpdCdzIGVmZmVjdGl2ZWx5 IHRoZSBzYW1lIGFzIDxlZGl0LWNvbmZpZz4uICAgT3RoZXJ3aXNlLCBpZiB0aGUgdG9wLWxldmVs IGZsYWcgaXMgJ3JlcGxhY2UnIGFuZCB0aGUgY29uZmlnIGlzIGh1Z2UsIHRoZW4gdGhlIGFtb3Vu dCBvZiBmYWN0b3J5LWRlZmF1bHQgY29uZmlnIHRoYXQgZ2V0cyByZXBsYWNlZCBpcyByZWxhdGl2 ZWx5IHNtYWxsLiAgU28gaXQgc2VlbXMgdGhhdCBvcHRpb24gKGIpIGlzIGVxdWFsbHkgdmlhYmxl IGluIHRoZSBjb250ZXh0IG9mIGh1Z2UgY29uZmlncy4NCg0KSSBwZXJzb25hbGx5IHByZWZlciBv cHRpb24gKGIpLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCBpdCdzIGJldHRlciBpbiB0aGlzIGNhc2Ug dG8gbm90IHJlcXVpcmUgdGhlIGNsaWVudCB0byBoYXZlIHRvIHVuZGVyc3RhbmQgZWRpdC1jb25m aWcgb3IgeWFuZy1wYXRjaC4gIFJlY2FsbCwgdGhlIGRldmljZSBpcyB0aGUgSFRUUCBjbGllbnQs IGFuZCB0aGUgbG9naWMgdGhhdCBpbXBsZW1lbnRzIHRoZSBib290c3RyYXBwaW5nIGNvZGUgbWF5 IGJlIGRpZmZlcmVudCB0aGFuIHRoZSBsb2dpYyB0aGF0IGtub3dzIGhvdyB0byBwcm9jZXNzIE5F VENPTkYgb3IgUkVTVENPTkYsIGF0IGxlYXN0IHRoaXMgaG93IEkndmUgc2VlbiBpdCBpbXBsZW1l bnRlZC4uLg0KDQpUaG91Z2h0cz8NCg0KS2VudA0KDQo= --_000_B6D31AF243F945908D8854E3248C8E68junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <53A5A9B695FC5D4EAFB370C04A5EE712@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5TbyBJ 4oCZdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBsZWFmIC0gYW55IHRob3VnaHRzPw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGxlYWYgY29uZmlnLWhhbmRsaW5nIHs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBlbnVtZXJhdGlvbiB7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0g bWVyZ2UgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7JnF1b3Q7TWVyZ2UgY29uZmlndXJhdGlvbiBpbnRvIGV4aXN0aW5nIHJ1bm5pbmcgY29u ZmlndXJhdGlvbi4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSByZXBsYWNlIHs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7UmVwbGFjZSBleGlz dGluZyBydW5uaW5nIGNvbmZpZ3VyYXRpb24gd2l0aCBwYXNzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbi4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSBlZGl0LWNv bmZpZyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O1Byb2Nlc3MgY29uZmlndXJhdGlvbiBhcyBhbiAmbHQ7ZWRpdC1jb25maWcmZ3Q7 IGRvY3VtZW50LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnVtIHlhbmctcGF0Y2ggezxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtQcm9jZXNzIGNv bmZpZ3VyYXRpb24gYXMgYSBZQU5HIFBhdGNoIGRvY3VtZW50LiZxdW90Ozs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIHdpc2gg ZWRpdC1jb25maWcgYW5kIHlhbmctcGF0Y2ggY291bGQgYmUgb3B0aW9ucy9mZWF0dXJlcywgYnV0 IHRoaXMgZG9lc27igJl0IHJlZHVjZSB0aGUgbnVtYmVyIG9mIGZvcm1hdHMgdGhhdCBkZXZpY2Vz IHdvdWxkIG5lZWQgdG8gc3VwcG9ydCwgYXMgbGltaXRpbmcgd2hhdCBhIHNwZWNpZmljIGJvb3Rz dHJhcC1zZXJ2ZXJzDQogc3VwcG9ydHMgZG9lc27igJl0IGxpbWl0IHdoYXQgb3RoZXIgYm9vdHN0 cmFwLXNlcnZlcnMgbWlnaHQgc3VwcG9ydC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktl bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0K PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5OZXRjb25m ICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNl biAmbHQ7a3dhdHNlbkBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5 LCBKdW5lIDI5LCAyMDE2IGF0IDY6NTMgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldGNvbmZA aWV0Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbTmV0Y29uZl0gemVyb3RvdWNoLzEyOiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVy Z2UvcmVwbGFjZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5UcnlpbmcgdG8gbW92ZSB0aGlzIGRpc2N1c3Npb24gZm9yd2FyZC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5J4oCZbSBzdGlsbCBwcmVmZXIgKGIpIGZvciB0aGUgcmVhc29ucyBsaXN0 ZWQgYmVsb3csIGJ1dCBpdCBtYXkgYmUgcG9zc2libGUgdG8gZG8gc29tZXRoaW5nIGluIGJldHdl ZW4gKGIpIGFuZCAoYykuJm5ic3A7IEluIHBhcnRpY3VsYXIsIGEgdG9wLWxldmVsIGZsYWcgY291 bGQgYWxsb3cgZm9yIGVkaXQtY29uZmlnIGFuZCB5YW5nLXBhdGNoDQogb3B0aW9ucyBhbHNvLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyYjNDM7LS06KGJvb3RzdHJhcC1pbmZv cm1hdGlvbik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBib290c3RyYXAtaW5mb3Jt YXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBi b290LWltYWdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7 IC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIGNv bmZpZ3VyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7 LS1ybyBzY3JpcHQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHN0cmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk5FVzo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyYjNDM7 LS06KGJvb3RzdHJhcC1pbmZvcm1hdGlvbik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1y byBib290c3RyYXAtaW5mb3JtYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyYjNDM7LS1ybyBib290LWltYWdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt8Jm5ic3A7IC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7JiM0MzstLXJvIGNvbmZpZy1oYW5kbGluZyZuYnNwOyBlbnVtIHtyZXBsYWNlLCBtZXJn ZSwgZWRpdC1jb25maWcsIHlhbmctcGF0Y2h9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmIzQzOy0tcm8gY29uZmlndXJhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8gc2NyaXB0PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5UaG91Z2h0cz8mbmJzcDsgLSBpcyBpdCB3b3J0aCBpdD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ S2VudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPk5ldGNv bmYgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0 c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIE1heSAxMSwgMjAxNiBhdCA3OjAzIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRjb25m QGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5bTmV0Y29uZl0gemVyb3RvdWNoLzEyOiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVyZ2Uv cmVwbGFjZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+aHR0 cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5TbGlkZSAxMCBmcm9tIHRoZSB6ZXJvIHRvdWNo IHByZXNvIEAgOTUgaGFkOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOyBPcHRpb25zOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6 YmxhY2siPkEuIEhhcmRjb2RlIOKAnXJlcGxhY2XigJ0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsvLyBhbHdheXMgd29ya3MsIGJ1dCBsYXJnZSBpbiBzaXplPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Qi4gVXNlIGEgdG9w LWxldmVsIGZsYWcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsvLyBsZXQgZGVwbG95 bWVudHMgZGVjaWRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjpibGFjayI+Qy4gVXNlIGVkaXQtY29uZmlnIG9yIHlhbmctcGF0Y2g/ICZu YnNwOyAmbmJzcDsmbmJzcDsvLyBpcyB0aGlzIG11Y2ggZ3JhbnVsYXJpdHkgbmVlZGVkPzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPlRoZSBtaW51dGVzIG5vdGUgdGhhdCBSaWNrIFRheWxvciBwcmVm ZXJzIHRoZSBsYXN0IG9wdGlvbiwgc3RhdGluZyB0aGF0IHRoZSBjb25maWd1cmF0aW9uIGNhbiBi ZSBiaWcuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkJ1dCBsZXQncyBjb25zaWRlciBv cHRpb24gKGIpIGluIHRoZSBjb250ZXh0IG9mIHRoZSBjb25maWcgYmVpbmcgYmlnLiAmbmJzcDsg SWYgdGhlIHRvcC1sZXZlbCBmbGFnIGlzICdtZXJnZScgYW5kIHRoZSBjb25maWcgaXMgaHVnZSwg dGhlbiBpdCdzIGVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzICZsdDtlZGl0LWNvbmZpZyZndDsuDQog Jm5ic3A7IE90aGVyd2lzZSwgaWYgdGhlIHRvcC1sZXZlbCBmbGFnIGlzICdyZXBsYWNlJyBhbmQg dGhlIGNvbmZpZyBpcyBodWdlLCB0aGVuIHRoZSBhbW91bnQgb2YgZmFjdG9yeS1kZWZhdWx0IGNv bmZpZyB0aGF0IGdldHMgcmVwbGFjZWQgaXMgcmVsYXRpdmVseSBzbWFsbC4gJm5ic3A7U28gaXQg c2VlbXMgdGhhdCBvcHRpb24gKGIpIGlzIGVxdWFsbHkgdmlhYmxlIGluIHRoZSBjb250ZXh0IG9m IGh1Z2UgY29uZmlncy4gJm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+SSBwZXJz b25hbGx5IHByZWZlciBvcHRpb24gKGIpLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCBpdCdzIGJldHRl ciBpbiB0aGlzIGNhc2UgdG8gbm90IHJlcXVpcmUgdGhlIGNsaWVudCB0byBoYXZlIHRvIHVuZGVy c3RhbmQgZWRpdC1jb25maWcgb3IgeWFuZy1wYXRjaC4gJm5ic3A7UmVjYWxsLCB0aGUgZGV2aWNl DQogaXMgdGhlIEhUVFAgY2xpZW50LCBhbmQgdGhlIGxvZ2ljIHRoYXQgaW1wbGVtZW50cyB0aGUg Ym9vdHN0cmFwcGluZyBjb2RlIG1heSBiZSBkaWZmZXJlbnQgdGhhbiB0aGUgbG9naWMgdGhhdCBr bm93cyBob3cgdG8gcHJvY2VzcyBORVRDT05GIG9yIFJFU1RDT05GLCBhdCBsZWFzdCB0aGlzIGhv dyBJJ3ZlIHNlZW4gaXQgaW1wbGVtZW50ZWQuLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5UaG91 Z2h0cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5LZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B6D31AF243F945908D8854E3248C8E68junipernet_-- From nobody Thu Jul 7 09:55:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6E12D822 for ; Thu, 7 Jul 2016 09:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmxstC2enyoc for ; Thu, 7 Jul 2016 09:55:19 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C37A12D827 for ; Thu, 7 Jul 2016 09:55:16 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id f7so12642367vkb.3 for ; Thu, 07 Jul 2016 09:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iMVYcDxUPsmCo9fGwQzw3j57lKjvaZtQ8dQrgnRagqU=; b=lvo4oj9hyTihUkNeukNgsQB6x180zZxAtPZ/FDGLyVDZ7Y+LQ9jL1xAVSjokRuu6vJ viVS1KOVpTOOQIvhmS1vHCTpe6vHcEXKWPoCVfbnhS63FhUQT7li6FM5JQJCYpGJjSqB UlKnlQsrEbMeJybO4TqtG7NBHh+S9r2VWclfkAfMOOjtEvyXbRtLe6ldCaxdC36/IuJt Vx2BL3anU7GD7JMJIs/FsUhEL+i9ZUHLMWI43cp34kbLHXuMsduaIwJEjmvBHasg+STm XkdYJTxptBJDysPmce/jMEDWlPKT9RnmMTrI+NgCcihfxtEtpTQs/9dzkcH28uERFPPr tWmg== 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; bh=iMVYcDxUPsmCo9fGwQzw3j57lKjvaZtQ8dQrgnRagqU=; b=DHDhrLoYdpZzOlv/ImYY4PXgoRujtrxcjhD+1brbvmvlzhx4TRZofQAEdfN5Ij+5Ni uCDExQZ/W2D0ugVn+bAjLd9T1C5WVpO6X69EFAdRbqL5hLZbJ/fMVr5NB/LA9WAo1pdY KdJ/3ZC7cyHIhgg5Z4JYmroz49xUREGBtDr9yI1Hv6nJjnPeABB1VFmkYiysMr3n8EI9 q4ELdw4HgPwDNpLk9pMzBf6XweL7gjcy8CFzw1XJJtLeeVvUqQpBnFITpIRv6MCNhLTo PSQVApRFmSlmtUTPgE+Lq33QU9Gw+inNCk3pNs0x+JTxC/FB0abWHBTbvPkFxWQJNSXC iDTQ== X-Gm-Message-State: ALyK8tKO9K+HoM9sHwbmxBHDPukUjyq2i0OPCvrdNv3tKikj7LsFV4DaIGxFDIDTGpKc6qdXe2Kyw3cXosF+AA== X-Received: by 10.31.4.4 with SMTP id 4mr578149vke.121.1467910515499; Thu, 07 Jul 2016 09:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Thu, 7 Jul 2016 09:55:14 -0700 (PDT) In-Reply-To: <8C077DAC-4A77-4467-9B2E-E04F226DBBC1@juniper.net> References: <8C077DAC-4A77-4467-9B2E-E04F226DBBC1@juniper.net> From: Andy Bierman Date: Thu, 7 Jul 2016 09:55:14 -0700 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a114298c8d6c16d05370e8cd7 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/17: How to verify boot-image integrity? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 16:55:22 -0000 --001a114298c8d6c16d05370e8cd7 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 6, 2016 at 6:16 PM, Kent Watsen wrote: > New issue: https://github.com/netconf-wg/zero-touch/issues/17 > > > > The current draft hardcodes the use of both the MD5 and SHA1 hash > algorithms for the purpose of enabling a device to verify a downloaded > boot-image, that may not have an embedded signature. > > > > +--ro boot-image > > +--ro modules > > | +--ro module* > > | +--ro name? yang:yang-identifier > > | +--ro revision? string > > +--ro name string > > +--ro md5 string > > +--ro sha1 string > > +--ro uri* inet:uri > > > > But a recommendation came (attribution?) to try to use a digest format > more generic and less obsolete. > > > > Here are some options: > > > > 0) do nothing, keep as md5 and shall > > 1) replace both with sha256 // still hardcoded, but current > > 2) define an identity base type ("digest-algorithm") and some derived > types for popular dgst lags > > > > Any other ideas? > I prefer option 1 I know using unbounded identityref is the latest fad, but this is really expensive on the client side. I will always prefer 1 mandatory mechanism over an unbounded set of optional-to-implement choices. A compromise is to use an identityref but make the sha256 identity mandatory-to-implement. > > > Thanks, > > Kent > Andy > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a114298c8d6c16d05370e8cd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 6, 2016 at 6:16 PM, Kent Watsen <kwatsen@juniper.net= > wrote:

New issue: https://github.com/netconf-wg/zero-touch/issues/17=

=C2=A0

The current draft h= ardcodes the use of both the MD5 and SHA1 hash algorithms for the purpose o= f enabling a device to verify a downloaded boot-image, that may not have an= embedded signature.

=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--ro boot-image

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro modules

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module*

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name?=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0yang:yang-identifier

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision?=C2=A0= =C2=A0 string

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = string

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro md5=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 string

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro sha1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = string

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro uri*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = inet:uri

=C2=A0

But a recommendatio= n came (attribution?) to try to use a digest format more generic and less o= bsolete.

=C2=A0

Here are some optio= ns:

=C2=A0

=C2=A0 0) do nothin= g, keep as md5 and shall

=C2=A0 1) replace b= oth with sha256 // still hardcoded, but current

=C2=A0 2) define an= identity base type ("digest-algorithm") and some derived types f= or popular dgst lags

=C2=A0

Any other ideas?



I prefe= r option 1

I know using unbounded identityref is t= he latest fad, but this is really expensive
on the client side.= =C2=A0 I will always prefer 1 mandatory mechanism over an
unbound= ed set of optional-to-implement choices.

A comprom= ise is to use an identityref but make the sha256 identity mandatory-to-impl= ement.

=C2=A0
=

=C2=A0

Thanks,

Kent



Andy
=C2= =A0

=C2=A0

=C2=A0


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


--001a114298c8d6c16d05370e8cd7-- From nobody Thu Jul 7 18:24:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D285E12D5C9 for ; Thu, 7 Jul 2016 18:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HYvYC0rYM4L for ; Thu, 7 Jul 2016 18:24:35 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0135.outbound.protection.outlook.com [104.47.34.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539B412D522 for ; Thu, 7 Jul 2016 18:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7YJ6CR8lZv6dQpxwq1t/DlteFpyDm/dtp9IJTwgCTyI=; b=RHiU2c2qRjPoe9fv0BR5W48GxdvpnrbG5lStYgcVBBE1iw+78iUXXkD8x8UIO0Mr4wlav1reKArBRvqxZ/x7srcLtR0eizPIbXrddfGpFc9IHMcu2efmMm9iIquHUho0W6oa+0bE7Yb9K4Rd9dyJhjzu1slpm9pBk/erU2/D9bg= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 8 Jul 2016 01:24:33 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.022; Fri, 8 Jul 2016 01:24:33 +0000 From: Kent Watsen To: Martin Bjorklund , "mjethanandani@gmail.com" Thread-Topic: [Netconf] Semi-configurable design in server model draft Thread-Index: AQHRt6undd9KBwAb2k2PocgHOjB2f5/MyM0AgABHOwCABBqFAIA8kgMA Date: Fri, 8 Jul 2016 01:24:33 +0000 Message-ID: <06ADB831-7279-426F-A506-6868D96F8FCF@juniper.net> References: <20160530.102622.281213031392882639.mbj@tail-f.com> In-Reply-To: <20160530.102622.281213031392882639.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 1c978e4f-09e5-414f-e6e0-08d3a6ce9e2b x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:uA7NnTVzow+nZHWgn91950T2LDWJnlpxUeCcGxCWXCog1tg3UevPQj9u6B7dGo9aznHzIcZj/jtXHLf4tBSeiOQiK7A4A2jgqV/7OVCEJaeW0VzlgS/bMUU+aMTsGYOhJyISIU9xtNTbcniZypOAKCaEbTDavA2lRNw99pxK8hhKxbpw5y77cIWySZVCtd/i2H4NjSaRUszbjtKEnNg/XqyYtpAcSM3Jg43rXdDFagk02ukzr2RwUoUhg/i7++HVVHUKxZqSduFTEmuv6SHGKhpLJn95331Xa8u8fgVxYDNENMg8OOisEAGDQj0zZlim99IPpldYM7WmejBb4/0oDg==; 5:DLN1Bq6FXJFTd9udK1V6xiEyi4ccvNNYFSaKwG0e08vhuM6i73Aci3TPWgbs/iHIKiyVxetaSAp8RBtsLcRq+/BpDotHTqq6/ilHSoEOCOMxRthOFVvBd+2L/5YvcmKAvO8mnmB7FeyNiR8+p84dsw==; 24:sYwnsSOgBrIGyT1UNLxd5ihSLzDFcFXrK944v8ScwjRI9wbMD5hcrZafS+2UPTJvRV5TLmLp1i5xHtzCi02G3Wjpka0vdyLj/Y8t5MMDRDM=; 7:AkZ8JyiNCrNIK+HEhVD6rpVLf02yRUIJ8B1CbAki/wO8xN/WcrqG8Bh8mbZQUupCWClX7JR7MrtIvbraMX1rlrxmrRlx0semWYGzq28ouxEGgdy0tOKfg5IH75ujzSB9kmNRSCir2emfGLoQCaDmfMEwpVJz/RITmQoWEN4arsZe76XEkja1DUXutxP7JrF4R6Jg0dAkm/2xyP3h5rM//rBFraBd3g/4PUozz2mJR4VGo4QYM1SDMnE1MfeVgsPe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(76104003)(24454002)(199003)(81166006)(19580405001)(77096005)(54356999)(86362001)(81156014)(4001350100001)(50986999)(305945005)(36756003)(2900100001)(10400500002)(68736007)(5001770100001)(2950100001)(92566002)(97736004)(99286002)(83506001)(19580395003)(33656002)(82746002)(87936001)(3846002)(7736002)(101416001)(7846002)(76176999)(122556002)(83716003)(2501003)(6116002)(102836003)(4326007)(5002640100001)(586003)(8936002)(11100500001)(106116001)(189998001)(105586002)(8676002)(3280700002)(93886004)(106356001)(66066001)(3660700001)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <358AE2605857A44E9CF7EFBE1162E4D9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 01:24:33.5872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Semi-configurable design in server model draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:24:38 -0000 DQpIaSBNYXJ0aW4sDQoNCknigJl2ZSBiZWVuIHRyeWluZyB0byBtYWtlIHNlbnNlIG9mIHlvdXIg c3VnZ2VzdGlvbiwgYnV0IG5vdGhpbmcgZml0cy4gICBUaGUgb25seSB0aGluayB0aGF0IG1ha2Vz IHNlbnNlIHRvIG1lIGlzIHRvIG1ha2Ug4oCccHJpdmF0ZS1rZXnigJ0gY29uZmlnIHRydWUsIHNv IGl04oCZcyBnZW5lcmFsbHkgY29uZmlndXJhYmxlLCBmb3Igcm91bmQtdHJpcHBpbmcuICBUaGVu LCB0byBoYW5kbGUgVFBNLXByb3RlY3RlZCBrZXlzLCB3ZSB1c2Ugc29tZXRoaW5nIGZyb20gdGhl IG9wc3RhdGUgc29sdXRpb24sIGFzIHRoZSBUUE0tcHJvdGVjdGVkIGtleXMgY291bGQgYmUgY29u c3RydWVkIGFzIOKAnHN5c3RlbSBnZW5lcmF0ZWTigJ0sIGF0IGxlYXN0IHRoZSBEZXZJRCBwcml2 YXRlLWtleSAodGhlIG9ubHkgVFBNLXByb3RlY3RlZCBrZXkgdGhhdCBJIGNhcmUgYWJvdXQpIGNv dWxkIGJlIHNlZW4gdGhhdCB3YXkuDQoNCkJ1dCB0aGlzIGRvZXNu4oCZdCBzb2x2ZSB0aGUgd2hv bGUgcHJvYmxlbS4gIFdoaWxlIHRoZSBJRGV2SUQgY2VydCBjb3VsZCBhbHNvIGJlIOKAnHN5c3Rl bSBnZW5lcmF0ZWTigJ0sIHRoZSBMRGV2SUQgY2VydCBpcyBub3QsIGFuZCBjb25maWcgdHJ1ZSBp biBpbnRlbmRlZCBjYW7igJl0IHBvaW50IHRvIGNvbmZpZyB0cnVlIGluIGFwcGxpZWQuICAgTWF5 YmUgd2UgaGlkZS9vdmVybG9vayB0aGlzIGJ5IGNsYWltaW5nIHRoYXQgc2V0dGluZyBhbiBMRGV2 SUQgY2VydGlmaWNhdGUgaXMgb3V0LW9mLXNjb3BlIHRvIHRoZSBtb2RlbCwgd2hhdCBkbyB5b3Ug dGhpbms/DQoNCktlbnQNCg0KDQoNCk9uIDUvMzAvMTYsIDQ6MjYgQU0sICJNYXJ0aW4gQmpvcmts dW5kIiA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0 aGFuYW5kYW5pQGdtYWlsLmNvbT4gd3JvdGU6DQo+IFtDaGFpciBoYXQgb2ZmXQ0KPiANCj4gPiBP biBNYXkgMjcsIDIwMTYsIGF0IDEwOjMxIEFNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVy Lm5ldD4gd3JvdGU6DQo+ID4gDQo+ID4gSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIGZvbGxv d2luZyBleGNoYW5nZSBoYXBwZW5lZCBvbiBBcHIgN3RoOg0KPiA+ICANCj4gPiA8a2VudD4NCj4g PiBZZXMsIHRoZSBhY3Rpb24gc3RhdGVtZW50cyBhcmUgaW50ZW5kZWQgdG8gdXBkYXRlIHRoZSBy dW5uaW5nDQo+ID4gZGF0YXN0b3JlLiAgUHJlc3VtYWJseSBiZWNhdXNlIHRoZSBhY3Rpb25zIGFy ZSBlaXRoZXIgZ2VuZXJhdGluZyBvcg0KPiA+IGxvYWRpbmcgYSBuZXcga2V5LCB0aGVyZSB3b3Vs ZCBub3QgYmUgYSByZWFsIHdvcmxkIGxvY2tpbmcgaXNzdWUsIGJ1dA0KPiA+IEkgY2FuIHNlZSBo b3cgdGhpcyBtaWdodCBsZWFkIHRvIHVuZGVzaXJhYmxlIHJlc3VsdHMuICBBY2Nlc3MgY29udHJv bA0KPiA+IChOQUNNKSB3YXMgcmVtb3ZlZCB3aGVuIHdlIG1vdmVkIHRvIHRoZSBrZXljaGFpbiBi YXNlZCBhcHByb2FjaCwgYnV0DQo+ID4gcHJlc3VtYWJseSB0aGUgcHJpdmF0ZSBrZXkgd291bGQg bmVlZCB0byBwcm90ZWN0ZWQgYnkNCj4gPiBuYWNtOmRlZmF1bHQtZGVueS1hbGwuDQo+ID4gIA0K PiA+IEkgc2VlIHdoYXQgeW91J3JlIHNheWluZy4gIFlvdSdyZSByaWdodCBhYm91dCB0aGlzIGJy ZWFraW5nIGJhY2t1cCBhbmQNCj4gPiByZXN0b3JlLiAgVGhlIG9ubHkgd2F5IHRvIGZpeCBpdCBp cyBmb3IgdGhlIGJhY2t1cCAoPGdldC1jb25maWc+KSB0bw0KPiA+IGNvbnRhaW4gdGhlIHByaXZh dGUga2V5cy4gIEJ1dCBub3RlIHRoYXQgc3lzdGVtcyB1c2luZyBhIFRQTSBhY3R1YWxseQ0KPiA+ IGhhdmUgTk8gV0FZIHRvIGdldCB0aGUgcHJpdmF0ZSBrZXkgb3V0IG9mIHRoZSBUUE0gLSBvbmx5 IHRoZSBUUE0NCj4gPiBpdHNlbGYgaGFzIGFjY2VzcyB0byB0aGUgcHJpdmF0ZSBrZXkuICBTbyBm b3IgdGhlc2Ugc3lzdGVtcywNCj4gPiBiYWNrdXAvcmVzdG9yZSAoUk1BKSBpcyBpbXBvc3NpYmxl LCBldmVuIHdpdGggcm9vdC1sZXZlbCBhY2Nlc3Mgb24gdGhlDQo+ID4gY29tbWFuZCBsaW5lLg0K PiA+ICANCj4gPiBJJ20gbm90IHN1cmUgaWYgSSB1bmRlcnN0YW5kIHlvdXIgZmlyc3Qgb3B0aW9u LiAgRG8geW91IG1lYW4gdGhlDQo+ID4gY2xpZW50IHdvdWxkIGNyZWF0ZSBhIGR1bW15IHByaXZh dGUga2V5IGVudHJ5IChhIHBsYWNlaG9sZGVyKSBhbmQgdGhlbg0KPiA+IGNhbGwgYW4gYWN0aW9u IHRvIHBvcHVsYXRlIHRoZSBrZXkgd2l0aCBkYXRhPw0KPiA+IDwva2VudD4NCj4gPiAgDQo+ID4g PG1hcnRpbj4NCj4gPiBZZXMsIGJ1dCBzaW5jZSB0aGUgcHJpdmF0ZSBrZXkgaXMgbm90IHBhcnQg b2YgdGhlIGNvbmZpZywgdGhlIGFjdGlvbg0KPiA+IHdpbGwgbm90IHRvdWNoIHRoZSBydW5uaW5n IGNvbmZpZy4NCj4gPiA8L21hcnRpbj4NCj4gPiAgDQo+ID4gPGtlbnQ+DQo+ID4gSSBkb24ndCB0 aGluayB0aGUgcHJpdmF0ZSBrZXlzIGNhbiBiZSBjb25maWcgZmFsc2UsIHNpbmNlIHRoZXkgYXJl DQo+ID4gcmVmZXJlbmNlZCBieSBjb25maWcgdHJ1ZSBub2RlcyBpbiB0aGUgdGxzL3NzaC1zZXJ2 ZXIgbW9kdWxlcy4NCj4gPiA8L2tlbnQ+DQo+ID4gIA0KPiA+IDxtYXJ0aW4+DQo+ID4gWW91IGNh biBoYXZlIGEgcmVxdWlyZS1pbnN0YW5jZSBmYWxzZSBsZWFmcmVmIHRvIHRoZSBjb25maWcgZmFs c2Ugb2YNCj4gPiBrZXlzLCBhbmQgdGhlbiBkZXNjcmliZSB3aGF0IHdpbGwgaGFwcGVuIGlmIHNv bWUgc2VydmVyIGlzIGNvbmZpZ3VyZWQNCj4gPiB0byBwb2ludCB0byBhIHByaXZhdGUga2V5IHRo YXQgZG9lc24ndCBleGlzdC4NCj4gPiAgDQo+ID4gVGhlcmUgYXJlIHN5c3RlbXMgd2l0aCB0YW1w ZXItcHJvb2YgaHcgdGhhdCB3b24ndCBhbGxvdyB5b3UgdG8gYWNjZXNzDQo+ID4gdGhlIGtleXMg dW5sZXNzIGEgcGh5c2ljYWwgdG9rZW4gaXMgcHJlc2VudCAoZS5nLiBhIFVTQiBzdGljaykuICBJ bg0KPiA+IHN1Y2ggc3lzdGVtcywgeW91IG1heSB2ZXJ5IHdlbGwgZW5kIHVwIHdpdGggY29uZmln IHRoYXQgcmVmZXJzIHRvIGENCj4gPiBrZXkgdGhhdCBpc24ndCBhdmFpbGFibGUuDQo+ID4gIA0K PiA+IFF1ZXN0aW9uIDE6ICBJZiB0aGUgcHJpdmF0ZSBrZXkgaXMgbm90IHN0b3JlZCBpbiBzcGVj aWFsIEhXLCBkbyB3ZQ0KPiA+ICAgd2FudCB0byBzdXBwb3J0IGJhY2t1cC9yZXN0b3JlIG9mIHN1 Y2gga2V5cz8NCj4gPiAgDQo+ID4gICBJZiB0aGUgYW5zd2VyIGlzIHllczoNCj4gPiAgICAgICBV c2UgYSBjb25maWcgbGlzdCBhbmQgYSBzZXBhcmF0ZSAtc3RhdGUgbGlzdC4NCj4gPiAgICAgICBN YWtlIGFsbCByZWZlcmVuY2VzIHBvaW50IHRvIHRoZSAtc3RhdGUgbGlzdCAoaW4gb3JkZXIgdG8g aGFuZGxlDQo+ID4gICAgICAgVFBNIGV0YykNCj4gPiAgDQo+ID4gICBJZiB0aGUgYW5zd2VyIGlz IG5vOg0KPiA+ICAgICAgIFVzZSBvbmx5IGEgY29uZmlnIGZhbHNlIGxpc3QgYW5kIGRlZmluZSBh Y3Rpb25zIHRvIG1hbmlwdWxhdGUNCj4gPiAgICAgICB0aGUgbGlzdC4NCj4gPiA8L21hcnRpbj4N Cj4gPiAgDQo+ID4gIA0KPiA+IFJlZ2FyZGluZyBNYXJ0aW7igJlzIHF1ZXN0aW9uICMxIChub3Rl OiB0aGVyZSB3YXNu4oCZdCBhIHF1ZXN0aW9uICMyKSwgSQ0KPiA+IHRoaW5rIHRoYXQgdGhlIGFu c3dlciBpcyDigJx5ZXMsIHdl4oCZZCBsaWtlIHRvIHN1cHBvcnQgYmFja3VwL3Jlc3RvcmUgb2YN Cj4gPiBwcml2YXRlIGtleXPigJ0uICBJcyB0aGlzIHRoZSBXR+KAmXMgb3BpbmlvbiBhcyB3ZWxs Pw0KPiANCj4gTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB5ZXMgYWxzby4gQnV0IEkgYW0gYSBsaXR0 bGUgY29uZnVzZWQgaGVyZS4gSWYNCj4gVFBNIGRvZXMgbm90IGFsbG93IGZvciBrZXlzIHRvIGJl IGV4cG9ydGVkLCB3aGF0IHdvdWxkIGJlIHJlZmxlY3RlZCBpbg0KPiB0aGUgLXN0YXRlIGxpc3Q/ DQoNClRoZSAtc3RhdGUgbGlzdCB3b3VsZCBjb250YWluIGp1c3QgdGhlIG5hbWUgb2YgdGhlIGtl eTsgbm90IHRoZSBrZXkNCml0c2VsZi4NCg0KPiBBbmQgaWYgYSBjb25maWcgdHJ1ZSBub2RlIHJl ZmVycyB0byB0aGlzIGNvbmZpZyBmYWxzZQ0KPiBub2RlLCB3aGF0IGFyZSB3ZSDigJxkZXNjcmli aW5n4oCdIHRoYXQgd2lsbCBoYXBwZW4/IElzIHRoZXJlIGEgd2hlbg0KPiBzdGF0ZW1lbnQ/DQoN CkZvciBleGFtcGxlLCBpZiB0aGUgaW50ZW5kZWQgY29uZmlnIG9mIHRoZSBORVRDT05GIHNlcnZl ciBjb250YWlucyBhDQpyZWZlcmVuY2UgdG8gYSBrZXkgdGhhdCBkb2Vzbid0IGV4aXN0IGluIC1z dGF0ZSwgZm9yIGV4YW1wbGUgYi9jIHRoZQ0Kc3BlY2lhbCBodyBjb3VsZG4ndCBiZSBhY2Nlc3Nl ZCwgdGhlbiB0aGUgTkVUQ09ORiBzZXJ2ZXIgd291bGRuJ3QgYmUNCnN0YXJ0ZWQuICBJZiB3ZSBo YXZlIHNvbWUgIm9wZXItc3RhdHVzIiBsZWFmIGZvciB0aGUgTkVUQ09ORiBzZXJ2ZXIsDQppdCBj b3VsZCBpbmRpY2F0ZSB0aGUgcmVhc29uIHRoYXQgdGhlIHNlcnZlciB3YXNuJ3Qgc3RhcnRlZA0K KCJtaXNzaW5nLWtleSIgb3Igc29tZXRoaW5nKS4NCg0KDQovbWFydGluDQoNCg0KDQoNCj4gDQo+ ID4gIA0KPiA+ICANCj4gPiBUaGFua3MsDQo+ID4gS2VudA0KPiA+ICANCj4gPiAgDQo+ID4gRnJv bTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWFoZXNo DQo+ID4gSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCj4gPiBEYXRlOiBU aHVyc2RheSwgTWF5IDI2LCAyMDE2IGF0IDg6MDYgUE0NCj4gPiBUbzogIm5ldGNvbmZAaWV0Zi5v cmciIDxuZXRjb25mQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFtOZXRjb25mXSBTZW1pLWNvbmZp Z3VyYWJsZSBkZXNpZ24gaW4gc2VydmVyIG1vZGVsIGRyYWZ0DQo+ID4gIA0KPiA+IE9uZSBvZiB0 aGUgaXNzdWVzIHRoYXQgS2VudCBicm91Z2h0IHVwIGluIHRoZSBpbnRlcmltIG1lZXRpbmcgd2Fz IHRoZQ0KPiA+IGlzc3VlIG9mIGNvbmZpZ3VyaW5nIHRoZSBwcml2YXRlIGtleS4gU29tZSBiYWNr Z3JvdW5kIG9uIHRoYXQgaXNzdWUNCj4gPiBkYXRlcyBiYWNrIHRvIHRoZSB0aHJlYWQgdGhhdCBz dGFydGVkIHdpdGggTWFydGluIHJldmlld2luZyB0aGUNCj4gPiBkb2N1bWVudCBhbmQgaGVyZSBp cyB3aGF0IGhlIGJyb3VnaHQgdXAgaW4gdGhhdCByZXZpZXcuDQo+ID4gIA0KPiA+IG8gIFNlY3Rp b24gNC4xDQo+ID4gIA0KPiA+ICAgSSB0aGluayB0aGUgInNlbWktY29uZmlndXJhYmxlIiBkZXNp Z24gaGFzIHNvbWUgaXNzdWVzLiAgWW91IGhhdmUNCj4gPiAgIGRlZmluZWQgc29tZSBhY3Rpb25z IHRoYXQgYWN0dWFsbHkgbW9kaWZpZXMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlDQo+ID4gICBz eXN0ZW0uICBJdCBpcyBub3QgY2xlYXIgd2hpY2ggY29uZmlnIGRhdGFzdG9yZSBpcyBtb2RpZmll ZC4NCj4gPiAgIFByZXN1bWFibHkgcnVubmluZy4gIEludGVyYWN0aW9ucyB3aXRoIGxvY2tpbmcg YW5kIGFjY2VzcyBjb250cm9sDQo+ID4gICBhcmUgbm90IGRlc2NyaWJlZC4gIEFsc28sIHRoZSBy ZXN1bHRpbmcgY29uZmlndXJhdGlvbiBpcyBub3QNCj4gPiAgIGNvbXBsZXRlIC0gaS5lLiwgeW91 IGNhbm5vdCBkbyA8Y29weS1jb25maWc+IHRvIHNhdmUvcmVzdG9yZSBhDQo+ID4gICBiYWNrdXAu ICBUaGlzIGlzIGZpbmUsIHNpbmNlIHlvdSByZWFsbHkgZG9uJ3Qgd2FudCB0byBleHBvc2UgdGhl DQo+ID4gICBwcml2YXRlIGtleXMgaW4gdGhlIGNvbmZpZyBiYWNrdXAuICBCdXQgc29tZSBkaXNj dXNzaW9uIGlzIG5lZWRlZA0KPiA+ICAgYXJvdW5kIHRoaXMgc3ViamVjdC4gIFdoYXQgaGFwcGVu cyBpZiBJIGdlbmVyYXRlIGEgcHJpdmF0ZSBrZXkgd2l0aA0KPiA+ICAgeW91ciBhY3Rpb24sIGJh Y2t1cCB0aGF0IGNvbmZpZyBhbmQgdGhlbiByZXN0b3JlIGl0PyAgV2hhdCBoYXBwZW5zDQo+ID4g ICB3aXRoIGNvbmZpZyB0aGF0IGhhcyByZWZlcmVuY2VzIHRvIHN1Y2ggYSBrZXk/DQo+ID4gIA0K PiA+ICAgT25lIHdheSB0byBhdm9pZCB0aGF0IHRoZSBhY3Rpb25zIG1vZGlmeSB0aGUgY29uZmln dXJhdGlvbiBjb3VsZCBiZQ0KPiA+ICAgdG8gbW92ZSB0aGVtIGludG8gdGhlIHByaXZhdGUta2V5 IGxpc3QuICBPbmUgZHJhd2JhY2sgaXMgdGhhdCB0d28NCj4gPiAgIG9wZXJhdGlvbnMgYXJlIG5l ZWRlZCBpbiBvcmRlciB0byBjcmVhdGUgYSAodXNhYmxlKSBrZXkgLSBmaXJzdA0KPiA+ICAgY3Jl YXRlIHRoZSBjb25maWcgaW4gcnVubmluZywgdGhlbiBjYWxsIHRoZSBhY3Rpb24uDQo+ID4gIA0K PiA+ICAgQW5vdGhlciBvcHRpb24gbWlnaHQgYmUgdG8gbW9kZWwgdGhlIGtleXMgYXMgY29uZmln IGZhbHNlIGRhdGEuDQo+ID4gICBUaGlzIGFsc28gc29sdmVzIHRoZSBwcm9ibGVtIHRoYXQgc29t ZSBrZXlzIChpbiBUUE0gZm9yIGV4YW1wbGUpDQo+ID4gICBhcmUgbm90IGRlbGV0YWJsZS4NCj4g PiBUaGUgdHdvIHN1Z2dlc3Rpb25zIHRoYXQgS2VudCBicm91Z2h0IHRvIHRoZSBtZWV0aW5nIG9u IHdoZXRoZXIgdG8NCj4gPiBtYWtlIGl0IGEgbGVhZiBvciBhbiBhY3Rpb24uDQo+ID4gIA0KPiA+ IExlYWZzIGNhbiBiZSBiYWNrZWQgdXAgb3IgcmVzdG9yZWQuIEJ1dCBwcml2YXRlLWtleXMgaW4g VFBNIG5ldmVyDQo+ID4gbGVhdmUgdGhlIHNvdXJjZS4gSG93IGRvIHdlIHN1cHBvcnQgc3BlY2lh bCBoYXJkd2FyZSBsaWtlIFRQTT8NCj4gPiAgDQo+ID4gTWFraW5nIGl0IGFuIGFjdGlvbiByZXF1 aXJlcyBjcmVhdGlvbiBvZiBhIGR1bW15IHByaXZhdGUga2V5LCBhbmQgdGhlbg0KPiA+IGNhbGwg YWN0aW9uIHRvIHBvcHVsYXRlIHRoZSBkYXRhIGluIGl0LCBhcyBNYXJ0aW4gc3RhdGVzIGFib3Zl LiBXaGF0DQo+ID4gaGFwcGVucyBpZiB0aGUga2V5IGlzIG5vdCBhdmFpbGFibGUgYnV0IGlzIHJl ZmVyZW5jZWQgYnkgdGhlIHN5c3RlbT8NCj4gPiAgDQo+ID4gS2VudCwgaXMgdGhhdCBhIGZhaXIg c3VtbWFyeSBvZiB0aGUgaXNzdWU/DQo+ID4gIA0KPiA+IExldCB0aGUgZGlzY3Vzc2lvbiBiZWdp biA6LSkNCj4gPiAgDQo+ID4gTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiA+IG1qZXRoYW5hbmRhbmlA Z21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQo+ID4gIA0KPiA+ICAN Cj4gPiAgDQo+IA0KPiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwu Y29tDQo+IA0KPiANCj4gDQo+IA0KPiANCg0KDQoNCg== From nobody Thu Jul 7 19:03:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC57126FDC for ; Thu, 7 Jul 2016 19:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Jmw3nGIhFR for ; Thu, 7 Jul 2016 19:03:33 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B375512B02D for ; Thu, 7 Jul 2016 19:03:33 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id v6so43837187vkb.2 for ; Thu, 07 Jul 2016 19:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YeNG/aw1HhYkk2XsWPHIGOYxUCQLOzj9o3P27uNkNEg=; b=E+CFTKQxzKECBDITRiItXZHToxySwotw+C9X5t9aDQVb5Nsu6s4fbRmZciHHlpGHcI XLBL1jngMlpx2Ku49nr8QjrDfq4KS11rS0YArd6LLdk27dgdSzCFqfgAg9tcyYN8pSkT yRrwr6b+HqxatItLfoctD9zx5iFt9L7mBnFqYrKzaVL/EY6ISn6e10CcnK+QaJNcx2V9 bYjBMKfFiPheQulUY7qinDhFd/sVz/deI62qf9SmXjUWNV2msOTeMy1CVPEDfQF7SIVm qLdnxx0S+JfjY3MebdW5wQphOzHj4ds3LuUDoD3pgGN2Sr6Uc07NVfpYILaNAW8UfQ+9 BsPg== 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; bh=YeNG/aw1HhYkk2XsWPHIGOYxUCQLOzj9o3P27uNkNEg=; b=hD25ScjgTp4Q/CiPKtk6ApXbYfCoYhzXXVTuuullnP1EFUOAHZY2Oddp5mKTz91dgD G0MWUzOaUFZRF/zTTMkII7h0WstgRJV9E3dkA2yocGF8Lijim1MyDVhoyRFYz22sV6Rb bkShI4LAQtWd4Tm7CoT9Ky/FsNJ2Lesi20E6Pk00O2GgqxD06WgEjxhQ9XbQLqtSz1rT HK8eZv5XkIy8i8d7CHG2t4AaAVtbcTTT0FoFnnOrQegSXzJf4K3zLRkMUn21XNMjzYbn KtitmU8vgzCVMwbj1gw3ABrRFy6197U+8pkCNLUthd3FAGpe6Mcn26pyuaSQJx08ifu6 sUqA== X-Gm-Message-State: ALyK8tJf9ZhFp9GKoKfXOXF25kT59KvLmrzwuHXej7h/E2xVmbrgkC6iZ+kUMPaz8n/NjF8cLqJNHvSVs/ZsSQ== X-Received: by 10.31.60.204 with SMTP id j195mr1601252vka.132.1467943412707; Thu, 07 Jul 2016 19:03:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Thu, 7 Jul 2016 19:03:32 -0700 (PDT) From: Andy Bierman Date: Thu, 7 Jul 2016 19:03:32 -0700 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary=001a1142fff0aa483c053716353b Archived-At: Subject: [Netconf] restconf: #68: separate draft for media type X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 02:03:36 -0000 --001a1142fff0aa483c053716353b Content-Type: text/plain; charset=UTF-8 Hi, I added another issue that was raised by Lada but not really addressed. https://github.com/netconf-wg/restconf/issues/68 I would like to resolve it on the mailing list instead of waiting until the meeting in Berlin. Andy --001a1142fff0aa483c053716353b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I added another issue that was rais= ed by Lada but not really addressed.


I would like to resolve it on the mailing list instead of
= waiting until the meeting in Berlin.



Andy

--001a1142fff0aa483c053716353b-- From nobody Thu Jul 7 21:40:50 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3C12D684; Thu, 7 Jul 2016 21:40:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708044045.18829.26837.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 21:40:45 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-15.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 04:40:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-15.txt Pages : 125 Date : 2016-07-07 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 21:42:17 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FAA12D684; Thu, 7 Jul 2016 21:42:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708044215.18627.10019.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 21:42:15 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 04:42:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-10.txt Pages : 36 Date : 2016-07-07 Abstract: This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 01:43:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826F912D08E for ; Fri, 8 Jul 2016 01:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 0odHJ6fn_Qrk for ; Fri, 8 Jul 2016 01:43:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7113B12B006 for ; Fri, 8 Jul 2016 01:43:35 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BD50FD00C7796 for ; Fri, 8 Jul 2016 08:43:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u688hXHV022369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Jul 2016 08:43:33 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u688hWkn019865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Jul 2016 10:43:32 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.62]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 10:43:32 +0200 From: "Bogaert, Bart (Nokia - BE)" To: "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-server-model Thread-Index: AdHY9M3Uv5gDLvxbTHydjqIWgPwiIA== Date: Fri, 8 Jul 2016 08:43:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01AF_01D1D905.9163DD80" MIME-Version: 1.0 Archived-At: Subject: [Netconf] draft-ietf-netconf-server-model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:43:42 -0000 ------=_NextPart_000_01AF_01D1D905.9163DD80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01B0_01D1D905.9163DD80" ------=_NextPart_001_01B0_01D1D905.9163DD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Not sure whether this has been mentioned already but I think there is a typo in the RESTCONF examples in section 4.1.2. The second example states the usage of the "load-private-key" action while in the request reference is made to the "generate-private-key" action. Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. >> ------=_NextPart_001_01B0_01D1D905.9163DD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Not sure = whether this has been mentioned already but I think there is a typo in = the RESTCONF examples in section 4.1.2.  The second example states = the usage of the “load-private-key” action while in the = request reference is made to the “generate-private-key” = action.

 

Best regards - = Vriendelijke groeten,

Bart = Bogaert

Broadband-Access= System Architect Data

Contact number = +32 3 2408310 (+32 477 673952)

 

NOKIA

Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis = 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities = Antwerp

<<
This message (including = any attachments) contains confidential information intended for a = specific individual and purpose, and is protected by law. If you are not = the intended recipient, you should delete this message. Any disclosure, = copying, or distribution of this message, or the taking of any action = based on it, is strictly prohibited without the prior consent of its = author.
>>

 

------=_NextPart_001_01B0_01D1D905.9163DD80-- ------=_NextPart_000_01AF_01D1D905.9163DD80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/TCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYzCCBkugAwIBAgIKXRYRuwAAAADQ8TANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDE2MDU1MjI4WhcNMTcwNDE1 MDU1MjI4WjBDMREwDwYDVQQDEwhib2dhZXJ0YjEuMCwGCSqGSIb3DQEJARYfYmFydC5ib2dhZXJ0 QGFsY2F0ZWwtbHVjZW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJBS7alw mZfOimfXIdJjyp1G8U+E4Rs5y+eXtDfKWEuy6UOCstRCUiSz+eljCu737ZPkMHmPMdXDHZGnsV9y HsInD5cZHBTNnboc8lV7zLVpTrtrnflClsOiRD75CS1Vvehx+JnFuW4Mo/VeWjQtUD4tUU67W7b0 QPOkcB3KkZixozjERSxPUFHf6pMShshwQlKtvV6YLdhnNePiuFimfYqUDiOQs1LR8C+r3eSMHi8o lyWTHf49vFPL7z62HWSldeEkf6vhtuZuWLfH7xqO3CIQH63zUJF9p23ko2/Gtc1MpAcdWMwV3ymj V8ef+gZac/SFwFgA547zeawhhvtdiOUCAwEAAaOCBBQwggQQMD0GCSsGAQQBgjcVBwQwMC4GJisG AQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisG AQQBgjcKAwQGCCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQB gjcKAwQwCgYIKwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTzjeedsBUMWk5eyOwD8/c9 1B1G8jAfBgNVHSMEGDAWgBTZ7Gu9llgi99imd83+TYHvupe9EjCCAV0GA1UdHwSCAVQwggFQMIIB TKCCAUigggFEhoHZbGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIwSW50ZXJuYWwlMjBTdWIl MjBDQSxDTj11c25hdnNwa2kwM3AsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0dHA6Ly9z ZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIBYQYIKwYB BQUHAQEEggFTMIIBTzCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQl MjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA4BggrBgEF BQcwAoYsaHR0cHM6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYB BQUHMAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3Vi Q0EuY3J0MCoGA1UdEQQjMCGBH2JhcnQuYm9nYWVydEBhbGNhdGVsLWx1Y2VudC5jb20wDQYJKoZI hvcNAQEFBQADggEBAEARoPJfuwXhstAQ/fAz/XKDC//Je9A0RG9Q5XV7+URvR5GxhwuikL/MEtXs Dspufv0eHG/b92AVZxaSgdpzC6neLoW2Q/Rdeavuifm7H/Ob645vIufqDQEqRqsyt9xRP+31VphA do994d7kU6v5BI7DAA8s5rl6h4PFbtvY5qe8VLNiTnon1dCwPQ+mRSrLfgjlZUw+WsMh69JEOWZX EufZMg0oUvCboUe3LNNvh8+DtLafaT1gS/kpv3c+dXVApTjb1tPbeZHc5L85AVQBsbq/vYpWhiZR qDiyVyPh+dh7vTa/GBJx/UVLwv6IswAwtCWZ/r9aReHssqkgMH9evF8xggQpMIIEJQIBATCBlDCB hTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1 Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwCQYFKw4DAhoFAKCCAmkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzA4MDg0MzMwWjAjBgkqhkiG9w0B CQQxFgQUyiMEHgief9FzAgF48lZUJbCAqPowgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQB+ k8iBuaSPxI17BaCP546hyJLG99rDj+Y4krwF42w59wFcaeTteqMaMDT/CTAqVqwX7UhnyqdIQlE9 Hd8nJ1vp6aeduVOJwk5qI6J/NZX76RI1bI0H09H0sPCXbnK5PXR/65V+3J8YyHEajRSVf6T0JuKl P65CbI0aAwboJtniBHw/GL+a2UKCoonezGT45wJ0ZGqVcLJoQc8XbEmQB6zV5xgOrUN6Gu5YCLm8 IxQBjEcKt0zLS2z+5adElhcEU2FQXgOwWaG6N8ZsAB0JnY5R8CfUp2djtyd4HcQwQiTCUqoQO3CF wkrNTUE6Yl+ulu51XNalADF95vvnZB1veEPtAAAAAAAA ------=_NextPart_000_01AF_01D1D905.9163DD80-- From nobody Fri Jul 8 02:25:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81312D115 for ; Fri, 8 Jul 2016 02:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fUC04qPOyXQ for ; Fri, 8 Jul 2016 02:25:30 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50131.outbound.protection.outlook.com [40.107.5.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122A312B044 for ; Fri, 8 Jul 2016 02:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G1FGKNi6Jrhr8S1pPpkHvcmfQU5zaI3lHr9VWkfVxc8=; b=Wmis/u/QOxuXEkkJQEJMdWB0BpFaXJWui/9E2bmQ4ETe1fKrf+xyP8qhnvqdo+oPp8PXx69Ac0QLpSpIju75QTWLBhVbYz2z2juVwGy/LejyAfVa+URIJOFhhzsdMjiTMBgXSX7gJ1faW08dRa3xyrpe+aFx2SiRqhXoX3A5h8I= Received: from AMXPR07MB215.eurprd07.prod.outlook.com (10.242.73.17) by AMXPR07MB215.eurprd07.prod.outlook.com (10.242.73.17) with Microsoft SMTP Server (TLS) id 15.1.523.12; Fri, 8 Jul 2016 09:25:26 +0000 Received: from AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.20]) by AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.20]) with mapi id 15.01.0523.028; Fri, 8 Jul 2016 09:25:26 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Netconf Thread-Topic: Test Thread-Index: AdHY+qALLvNt8VFrQU6gaBeddXTUwg== Date: Fri, 8 Jul 2016 09:25:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; x-originating-ip: [217.251.12.5] x-ms-office365-filtering-correlation-id: 51617c5e-88d4-40eb-1fa5-08d3a711cc0e x-microsoft-exchange-diagnostics: 1; AMXPR07MB215; 6:bIaLGLLbF4dO0vtuYcyyvSloo3iLM8C4ygubEc7ShHLDGanbhDQekboDw6s8G7G93sTu7jnf5tbaNGXBiY8UoV1g24uqtTjEqA8BmBJ5QUh+jmSYWA800SSmb2fm0/7It8f6sHlZn16CUJ8QJaASle67JZnrgEquoEV8Y2Xi4IzTFiQsKOFpQHzoWzs2S2VVTsqe5dYdUJ18E4wr11JgyNwe7rE9kGyqDqe+aQsE0gjdgD9vDE0wrGBQQWKcRPER1dKIV563SSuX+yWnvE+OXxUU2cfWftg87FCFoTBT7bg=; 5:ayy/PpkxE1wMnO3m8z334izGS8fXJw4pvq9f8OYfdDBHr71Ra+t5RpY7Gps22+KCHbn9/PpCoKxFVCBgmG29qqHOdPaNZYEj680oxpfY/btoOI1nqGQrnZXiArNwXOITAUOmkXkjx2FC8XPln4YfiQ==; 24:gCA+VNOSs6abf+8V/MjjIDfuTZj8kATfIYumbidUx836xgupAOv22qOjq6Sv6rjgvADZZTkHn2PI8dKOcSO071CMIak0rNQ5JA7xEpKc1LQ=; 7:Vt91RaM1DHtQLSKNEjxxtMvq9pxhHo1FI++qsMYxZbKa4vSHpeujeo8lfLWUkEUjR6ZJabnxaRHmruqh38ZUi9JhXIvLFzEP9epUr7zI89tvfXy+jtlgqrwewnqP8vIzKxPj0JrwY2aJXwoSwPqMn2pPML2+vpbN22odEjelYiCbZLe2wBr5ILVc7V7RVKHdh8Wvq67cpGeR7ecFUXnSeTLTrI+hqcRszpeJaW9WM6IGmSSLzDYkiQvqD7Mgyx/G x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB215; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMXPR07MB215; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB215; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(2900100001)(189998001)(101416001)(5002640100001)(10400500002)(97736004)(81156014)(92566002)(11100500001)(15975445007)(8676002)(81166006)(8936002)(110136002)(122556002)(221733001)(3480700004)(19580395003)(7846002)(2906002)(107886002)(9686002)(33656002)(74316002)(7696003)(5003600100003)(305945005)(7736002)(50986999)(3280700002)(3660700001)(586003)(66066001)(68736007)(54356999)(76576001)(3846002)(450100001)(6116002)(86362001)(106356001)(229853001)(105586002)(102836003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB215; H:AMXPR07MB215.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:tr; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMXPR07MB215359FFB3734F7D4611D61913C0AMXPR07MB215eurprd_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 09:25:26.8122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB215 Archived-At: Subject: [Netconf] Test X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:25:32 -0000 --_000_AMXPR07MB215359FFB3734F7D4611D61913C0AMXPR07MB215eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mehmet --_000_AMXPR07MB215359FFB3734F7D4611D61913C0AMXPR07MB215eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mehmet
 
 
 --_000_AMXPR07MB215359FFB3734F7D4611D61913C0AMXPR07MB215eurprd_-- From nobody Fri Jul 8 07:22:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B02812D501 for ; Fri, 8 Jul 2016 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVjE7_bbh8fM for ; Fri, 8 Jul 2016 07:22:36 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0091.outbound.protection.outlook.com [104.47.32.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955B512B051 for ; Fri, 8 Jul 2016 07:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jdbK4aMbkygL2orQA1gOtSfGThX/XN7VXe1gdtU2R+Y=; b=Hl+q0cnDx6nxc35w9bWskx7MRryUTGgFl1c6YeO/uYz8zsoInDeKc1+JfNPzv8IAIW2gl6n631YAZZrlcHlQr+KlsCOEYD3M13Zo49y++BPg99zJd6Ywi5xPc6m4R4c7kKQe5NLWx1/N1mTv53iKT5v2GJk75ELCMmUhNAE0m8U= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 8 Jul 2016 14:22:35 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.024; Fri, 8 Jul 2016 14:22:35 +0000 From: Kent Watsen To: "Bogaert, Bart (Nokia - BE)" , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-server-model Thread-Index: AQHR2SQrWUV2N7NQ9USEHWxLvHkkQg== Date: Fri, 8 Jul 2016 14:22:35 +0000 Message-ID: <959C4D0C-30D9-49C5-8F7B-6E5ED44A0067@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 0fe7a446-54fa-4d83-25da-08d3a73b4e8b x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:+onWG8275S7Udqf7hBHupgMvgEYFO35+kW0HWIh6THD1wCoqJev57artxjmeIl2+duC3tWB75XFzOd6iA1Mjvb+i5mMGw5MANnEP1QivCHDWAiuQz83QkmBqUR+U7KPyeSCZa9Ycl0evAMWds6L76FauCqWCvePSGy5Oq7hEpDUDoKIj+hMLo5ffzQOKIecEjPQ1UgEYF7S82++TodL8D3Hni9avhL6/X/I00AFVWO4mcE8Q56VZaTFuNk8ZhNf+Z31g/IkyFEfNRrmdcPwlf/v/H8YPFL3jlpQN+N0NBlfTO0Q7JKpwrz5cxCrFqUP1Q+9mz+pNbU0Twe0cXjfGmw==; 5:OGuMdVkDd1pPSZYlVFdG2M2cjRUT7g6CqqNwrfHeWE+G6aQpxKTBYse9lre6eHXwaOacpzGUKVkbfkLAU3yVWGHyS2L1KJf3bY4EufOZ623hFChWTrY9sJRRTOPZ5zsYEi9Kx2V+TNM7aas4Cy0mrA==; 24:lGmIkZFb/CXTVtpVGjgSquoZoiABkjLOMa+d8/vSSCqMBJV5B7kgxNWMQdwN/IlhIRa7g2nHJS/o38O6MHPZIXoOfqp6f+BW73Tu8zqmhiA=; 7:XaGxxCR2oT5IDs713qFKKSNxNwcW4vEZPcVZ+Mt+cRoFQm9ztsoSeiA01ypLxM5jSSYM47QBT2B3+SMFRkzIkRewpX1qLMIEvLKteX2rboXFcDAhL279SLiloKWDdcXqEUdk2+lXHR8M8ymKkO3R5TQ2hDMaeboIsCapqDPLltFkaagKcwo/7mJ1YCdU96iW2UMjf5y+GQ0hBnNRsqt1d9mNijyO4dUA/emRj5Khf18bMTuKJ7z7RQwnbmQrTulF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(21748063052155)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(19625215002)(66066001)(2501003)(2900100001)(107886002)(122556002)(99286002)(106356001)(11100500001)(8936002)(86362001)(82746002)(2906002)(3660700001)(15975445007)(68736007)(230783001)(33656002)(83506001)(101416001)(77096005)(189998001)(106116001)(19580405001)(586003)(105586002)(10400500002)(81156014)(7846002)(19300405004)(9326002)(16236675004)(3280700002)(87936001)(5890100001)(102836003)(6116002)(3846002)(92566002)(5001770100001)(5002640100001)(7736002)(97736004)(54356999)(50986999)(19580395003)(4001350100001)(36756003)(81166006)(8676002)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_959C4D0C30D949C58F7B6E5ED44A0067junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2016 14:22:35.1402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-server-model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:22:39 -0000 --_000_959C4D0C30D949C58F7B6E5ED44A0067junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBCYXJ0LA0KDQpUaGFua3MgZm9yIHJlcG9ydGluZyB0aGlzIC0gaXQgd2lsbCBiZSBmaXhl ZCBpbiB0aGUg4oCcc3lzdGVtLWtleWNoYWlu4oCdIGRyYWZ0IEkgd2lsbCBwb3N0IGxhdGVyIHRv ZGF5Li4uDQoNCktlbnQNCg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgIkJvZ2FlcnQsIEJhcnQgKE5va2lhIC0gQkUpIiA8YmFydC5ib2dhZXJ0 QG5va2lhLmNvbT4NCkRhdGU6IEZyaWRheSwgSnVseSA4LCAyMDE2IGF0IDQ6NDMgQU0NClRvOiAi bmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTmV0Y29uZl0g ZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbA0KDQpIaSwNCg0KTm90IHN1cmUgd2hldGhl ciB0aGlzIGhhcyBiZWVuIG1lbnRpb25lZCBhbHJlYWR5IGJ1dCBJIHRoaW5rIHRoZXJlIGlzIGEg dHlwbyBpbiB0aGUgUkVTVENPTkYgZXhhbXBsZXMgaW4gc2VjdGlvbiA0LjEuMi4gIFRoZSBzZWNv bmQgZXhhbXBsZSBzdGF0ZXMgdGhlIHVzYWdlIG9mIHRoZSDigJxsb2FkLXByaXZhdGUta2V54oCd IGFjdGlvbiB3aGlsZSBpbiB0aGUgcmVxdWVzdCByZWZlcmVuY2UgaXMgbWFkZSB0byB0aGUg4oCc Z2VuZXJhdGUtcHJpdmF0ZS1rZXnigJ0gYWN0aW9uLg0KDQpCZXN0IHJlZ2FyZHMgLSBWcmllbmRl bGlqa2UgZ3JvZXRlbiwNCkJhcnQgQm9nYWVydA0KQnJvYWRiYW5kLUFjY2VzcyBTeXN0ZW0gQXJj aGl0ZWN0IERhdGENCkNvbnRhY3QgbnVtYmVyICszMiAzIDI0MDgzMTAgKCszMiA0NzcgNjczOTUy KQ0KDQpOT0tJQQ0KQ29wZXJuaWN1c2xhYW4gNTAsIDIwMTggQW50d2VycCwgQmVsZ2l1bQ0KRm9y dGlzIDIyMC0wMDAyMzM0LTQyDQpWQVQgQkUgMDQwNCA2MjEgNjQyIFJlZ2lzdGVyIG9mIExlZ2Fs IEVudGl0aWVzIEFudHdlcnANCg0KDQo8PA0KVGhpcyBtZXNzYWdlIChpbmNsdWRpbmcgYW55IGF0 dGFjaG1lbnRzKSBjb250YWlucyBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y IGEgc3BlY2lmaWMgaW5kaXZpZHVhbCBhbmQgcHVycG9zZSwgYW5kIGlzIHByb3RlY3RlZCBieSBs YXcuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBzaG91bGQgZGVs ZXRlIHRoaXMgbWVzc2FnZS4gQW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIG9yIGRpc3RyaWJ1dGlv biBvZiB0aGlzIG1lc3NhZ2UsIG9yIHRoZSB0YWtpbmcgb2YgYW55IGFjdGlvbiBiYXNlZCBvbiBp dCwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCB3aXRob3V0IHRoZSBwcmlvciBjb25zZW50IG9mIGl0 cyBhdXRob3IuDQo+Pg0KDQo= --_000_959C4D0C30D949C58F7B6E5ED44A0067junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <89DB254F141A874F8C83AED6498A3AC6@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJOb2tpYSBQdXJlIFRleHQiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxp YnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1z by1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVh bDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJhcnQsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3IgcmVwb3J0aW5nIHRoaXMgLSBpdCB3aWxsIGJlIGZpeGVkIGluIHRoZSDi gJxzeXN0ZW0ta2V5Y2hhaW7igJ0gZHJhZnQgSSB3aWxsIHBvc3QgbGF0ZXIgdG9kYXkuLi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OZXRjb25mICZsdDtuZXRjb25mLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtCb2dhZXJ0LCBCYXJ0IChOb2tp YSAtIEJFKSZxdW90OyAmbHQ7YmFydC5ib2dhZXJ0QG5va2lhLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+RnJpZGF5LCBKdWx5IDgsIDIwMTYgYXQgNDo0MyBBTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7bmV0Y29uZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+W05ldGNvbmZdIGRyYWZ0LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9kZWw8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHN1cmUgd2hldGhlciB0aGlz IGhhcyBiZWVuIG1lbnRpb25lZCBhbHJlYWR5IGJ1dCBJIHRoaW5rIHRoZXJlIGlzIGEgdHlwbyBp biB0aGUgUkVTVENPTkYgZXhhbXBsZXMgaW4gc2VjdGlvbiA0LjEuMi4mbmJzcDsgVGhlIHNlY29u ZCBleGFtcGxlIHN0YXRlcyB0aGUgdXNhZ2Ugb2YgdGhlIOKAnGxvYWQtcHJpdmF0ZS1rZXnigJ0g YWN0aW9uIHdoaWxlIGluIHRoZSByZXF1ZXN0IHJlZmVyZW5jZSBpcyBtYWRlIHRvIHRoZQ0KIOKA nGdlbmVyYXRlLXByaXZhdGUta2V54oCdIGFjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iTkwtQkUiIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMUM3NUI5 Ij5CZXN0IHJlZ2FyZHMgLSBWcmllbmRlbGlqa2UgZ3JvZXRlbiw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTC1CRSIgc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOiMxQzc1QjkiPkJhcnQgQm9nYWVydDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlh bDtjb2xvcjojMUM3NUI5Ij5Ccm9hZGJhbmQtQWNjZXNzIFN5c3RlbSBBcmNoaXRlY3QgRGF0YTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpBcmlhbDtjb2xvcjojMUM3NUI5Ij5Db250YWN0IG51bWJlciAmIzQzOzMyIDMg MjQwODMxMCAoJiM0MzszMiA0NzcgNjczOTUyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Tm9r aWEgUHVyZSBUZXh0JnF1b3Q7O2NvbG9yOiMwMDcwQzAiPk5PS0lBPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvcGVybmljdXNsYWFuIDUwLCAyMDE4IEFu dHdlcnAsIEJlbGdpdW08YnI+DQpGb3J0aXMgMjIwLTAwMDIzMzQtNDI8YnI+DQpWQVQgQkUgMDQw NCA2MjEgNjQyIFJlZ2lzdGVyIG9mIExlZ2FsIEVudGl0aWVzIEFudHdlcnA8YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6Z3JheSI+Jmx0OyZsdDs8YnI+DQpUaGlzIG1lc3NhZ2UgKGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGNvbnRhaW5zIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3IgYSBzcGVjaWZpYyBpbmRpdmlkdWFsIGFuZCBwdXJwb3NlLCBhbmQgaXMg cHJvdGVjdGVkIGJ5IGxhdy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IHNob3VsZCBkZWxldGUgdGhpcyBtZXNzYWdlLiBBbnkgZGlzY2xvc3VyZSwgY29weWluZywg b3IgZGlzdHJpYnV0aW9uDQogb2YgdGhpcyBtZXNzYWdlLCBvciB0aGUgdGFraW5nIG9mIGFueSBh Y3Rpb24gYmFzZWQgb24gaXQsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgd2l0aG91dCB0aGUgcHJp b3IgY29uc2VudCBvZiBpdHMgYXV0aG9yLjxicj4NCiZndDsmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQiPiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_959C4D0C30D949C58F7B6E5ED44A0067junipernet_-- From nobody Fri Jul 8 09:19:01 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3612D1E6; Fri, 8 Jul 2016 09:19:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708161859.32059.98347.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 09:18:59 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:19:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Zero Touch Provisioning for NETCONF or RESTCONF based Management Authors : Kent Watsen Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-09.txt Pages : 73 Date : 2016-07-08 Abstract: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 11:26:52 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8F12D18E; Fri, 8 Jul 2016 11:26:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708182650.32156.42442.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 11:26:50 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-system-keychain-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:26:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : System Keychain Model Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-system-keychain-00.txt Pages : 33 Date : 2016-07-08 Abstract: This document defines a YANG data module for a system-level keychain mechanism, that might be used to hold onto private keys and certificates that are trusted by the system advertising support for this module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-system-keychain/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-system-keychain-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 13:01:18 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7512D0AD; Fri, 8 Jul 2016 13:01:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708200116.32087.82639.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 13:01:16 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-tls-client-server-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:01:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : TLS Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-tls-client-server-00.txt Pages : 15 Date : 2016-07-08 Abstract: This document defines two YANG modules, one defines groupings for a generic TLS client and the other defines groupings for a generic TLS server. It is intended that these groupings will be used by applications using the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 13:44:51 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF5112D119; Fri, 8 Jul 2016 13:44:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708204449.32168.92489.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 13:44:49 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-client-server-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:44:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : RESTCONF Client and Server Models Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-restconf-client-server-00.txt Pages : 23 Date : 2016-07-08 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 16:10:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA4212D14D for ; Fri, 8 Jul 2016 16:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOKEHQDnehAl for ; Fri, 8 Jul 2016 16:10:40 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC04412D0DC for ; Fri, 8 Jul 2016 16:10:39 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id b192so73390777vke.0 for ; Fri, 08 Jul 2016 16:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+WdgZEGIOHldnl8u6SKjysW33K+Qww/UfmbfGCvjFBQ=; b=FF7tVNhnn1qPY3JpJ2nV2K1MX2S48+AssdzXW70xNGJK5BSVSBbprTH1LA6qwS3kkC UAPau9XPECIi/w3Yckx9MYMqnjre4XTG29zAGkc92CGIDQZOhtcFEHY32OMhxPeZKL+f l2MRS6AipIK3Ff7kCrJTpEy46WdddSoGlmDxhclpXKLY9UtwKXvPzGyN75G8+sbnZKYZ x5VViBQX2sgX0WOd18eP1VUciA8PI5WmegoYh86B1bqq0R3rfaJU+CzdBK88EYvVDFxL xudtf85rNgt0Ta2w8Co67Z7zJRGYGlMrKJv0p1EImeLAUkyZ4BKzKm/BpwM2pDDbg8YO HcjQ== 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; bh=+WdgZEGIOHldnl8u6SKjysW33K+Qww/UfmbfGCvjFBQ=; b=bQMImqfcRNyCZH+xC3gs/nvtPkkPl947feLLlSCbVqUe5oUDFwQm9FSlfSLDmI0ybh v2DjiWiL55goMnFsLkjQh6aU5mR3phKDozayC1gpxERTDp6HLVX5qd8reW497ZiBH/I4 1oNTBKcjz4ks+3mKxgZlJj7cI+FL1tg2D+F/h9qHpbNCTMfbHKstZ7FVD5sESDU2UzmM 5WO2iSHGQ6VpYy42LuHfGJlDBrE3HsLyww/eBoJe6+LcK+G7LoUl5UWGxFkzUZwP56e+ IWnO32bRN371Mn2DgyEYdsIWEkFYo63bR3A9XKz1wZU3/8l/rAZ0y+ESxtXFj3LvenBh CYuw== X-Gm-Message-State: ALyK8tI1vt2zFd2GoqrUffi5A8wQ1DfmYgtsRpu2TX5My/66mQBhm/InJmelAN74oCsQJOmvUfTgGgTHkAOwTw== X-Received: by 10.159.35.112 with SMTP id 103mr3945437uae.55.1468019438744; Fri, 08 Jul 2016 16:10:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:38 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:38 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=001a113ab81a2b89f4053727e972 Archived-At: Subject: [Netconf] review request for media type application/yang-data X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:10:42 -0000 --001a113ab81a2b89f4053727e972 Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-data media type registration request (was application/yang-data+xml) Type name: application Subtype name: yang-data Required parameters: None Optional parameters: None // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with // the actual RFC reference for YANG 1.1, and remove this note. Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG defined data structures. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .xml Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no --001a113ab81a2b89f4053727e972 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised appl= ication/yang-data media type registration request
(was applicatio= n/yang-data+xml)
      Type name: application

      Subtype name: yang-data

      Required parameters: None

      Optional parameters: None

     // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
     // the actual RFC reference for YANG 1.1, and remove this note.

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to the
         XML Encoding Rules and Canonical Format for the specific
         YANG data node type defined in [draft-ietf-netmod-rfc6020bis].

     // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
     // section number for Security Considerations
     // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
     // RFC number, and remove this note.

      Security considerations: Security considerations related
         to the generation and consumption of RESTCONF messages
         are discussed in Section NN of [RFCXXXX].
         Additional security considerations are specific to the
         semantics of particular YANG data models. Each YANG module
         is expected to specify security considerations for the
         YANG data defined in that module.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Interoperability considerations: [RFCXXXX] specifies the
         format of conforming messages and the interpretation
         thereof.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Published specification: RFC XXXX

      Applications that use this media type: Instance document
        data parsers used within a protocol or automation tool
        that utilize YANG defined data structures.

      Fragment identifier considerations: The fragment field in the
         request URI has no defined purpose.

      Additional information:

        Deprecated alias names for this type: N/A
        Magic number(s): N/A
        File extension(s): .xml
        Macintosh file type code(s): "TEXT"

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Person & email address to contact for further information: See
         Authors' Addresses section of [RFCXXXX].

      Intended usage: COMMON

      Restrictions on usage: N/A

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Author: See Authors' Addresses section of [RFCXXXX].

      Change controller: Internet Engineering Task Force
         (mailto:iesg&=
amp;ietf.org).

      Provisional registration? (standards tree only): no

--001a113ab81a2b89f4053727e972-- From nobody Fri Jul 8 16:10:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31912D8D2 for ; Fri, 8 Jul 2016 16:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DB8ezAWZzME for ; Fri, 8 Jul 2016 16:10:45 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA0112D8DE for ; Fri, 8 Jul 2016 16:10:45 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id v6so73442925vkb.2 for ; Fri, 08 Jul 2016 16:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8DkUvmyWzb0WeJXM17dp5K7dT2H9DoUOCwD5c+xowA8=; b=ST+i3fLozcItD7jXEIkIQenIljagkL2wvGcvIM+oZG/JWSx6XTTdx+FQJEQLPCvjM1 8k4kXA7zvumfABKqSHZTTtH9xMceoCipR/JLfsXJf317nvASn9heTrtqnqqnLI3kmpns 6Nm9nPszFF78ooDtNqWEhnk1vYR//LOdu7LOsMSt6JCsfTVf3i7jSqV7wZcDCNqoK360 BCoi/oFiNfbDoDqBhuzlCGvUMCEltpwy1SOzzhOk1NpkbbSPLKRYgqpFYsl1UjbigzUt SyuO222xVLwwXphdXIswh6a7tcof91OKRP7ic4Mp72vjVXHVx+Gk1TiA/WuEt937JYWZ m77g== 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; bh=8DkUvmyWzb0WeJXM17dp5K7dT2H9DoUOCwD5c+xowA8=; b=OtRBDNt8rZe6nHFdbhojoGx1ABarJCl3kCknmOowjjFIYmwdMIb1U31kQ54iUA/NJJ 2IZh4WIzm3PjRMnLRAjs/uQG9dUSsFUhz+u2BAmN5qjCDUnjYJDyDbWK3NKYVxKVYn0R 42Dd+10iMi4NIj4rrTTC+CvtIpe5+yz+cbnbpVyZm2tzZmecGmqwvU7p4SfhGxJZM7SI 66GfY/6T+OKM4KIzNoMpd1D01glMmHQgEEe5pl241ikyBd9sYh1d3d4nW74AbOypGwoF QJ5v3hlL7L3cJAs6eMYX/bxMSr4G03wgFmHksw7c3Pv8DqLAz0VontrG3nuMOvFW/Wkk /Bog== X-Gm-Message-State: ALyK8tJOjh8EC1BUF3hCmWrz8Z3XY+BqXugMDrIYL0fuCvrqL9NHLI2L+J+9DrSoZBJBTvrnSFx6RT/PMUtc+w== X-Received: by 10.31.232.67 with SMTP id f64mr3353543vkh.44.1468019444536; Fri, 08 Jul 2016 16:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:43 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:43 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=94eb2c09493a83f969053727e92d Archived-At: Subject: [Netconf] review request for media type application/yang-data+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:10:47 -0000 --94eb2c09493a83f969053727e92d Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-data+json media type registration request Type name: application Subtype name: yang-data+json Required parameters: None Optional parameters: None // RFC Ed.: replace draft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace draft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [draft-ietf-netmod-yang-json]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata] // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize YANG defined data structures. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .json Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no --94eb2c09493a83f969053727e92d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised appl= ication/yang-data+json media type registration request

      Type name: application

      Subtype name: yang-data+json

      Required parameters: None

      Optional parameters: None

     // RFC Ed.: replace draft-ietf-netmod-yang-json with
     // the actual RFC reference for JSON Encoding of YANG Data,
     //  and remove this note.

     // RFC Ed.: replace draft-ietf-netmod-yang-metadata with
     // the actual RFC reference for JSON Encoding of YANG Data,
     //  and remove this note.

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to
         [draft-ietf-netmod-yang-json]. A data annotation is
         encoded according to [draft-ietf-netmod-yang-metadata]

     // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
     // section number for Security Considerations
     // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
     // RFC number, and remove this note.

      Security considerations: Security considerations related
         to the generation and consumption of RESTCONF messages
         are discussed in Section NN of [RFCXXXX].
         Additional security considerations are specific to the
         semantics of particular YANG data models. Each YANG module
         is expected to specify security considerations for the
         YANG data defined in that module.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Interoperability considerations: [RFCXXXX] specifies the format
         of conforming messages and the interpretation thereof.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Published specification: RFC XXXX

      Applications that use this media type: Instance document
        data parsers used within a protocol or automation tool
        that utilize YANG defined data structures.

      Fragment identifier considerations: The syntax and semantics
         of fragment identifiers are the same as specified for the
        "application/json" media type.

      Additional information:

        Deprecated alias names for this type: N/A
        Magic number(s): N/A
        File extension(s): .json
        Macintosh file type code(s): "TEXT"

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Person & email address to contact for further information: See
         Authors' Addresses section of [RFCXXXX].

      Intended usage: COMMON

      Restrictions on usage: N/A

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Author: See Authors' Addresses section of [RFCXXXX].

      Change controller: Internet Engineering Task Force
         (mailto:iesg&=
amp;ietf.org).

      Provisional registration? (standards tree only): no
--94eb2c09493a83f969053727e92d-- From nobody Fri Jul 8 16:11:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537B712D95F for ; Fri, 8 Jul 2016 16:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT3Uf4byvaoh for ; Fri, 8 Jul 2016 16:10:55 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D6012D925 for ; Fri, 8 Jul 2016 16:10:50 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id f7so58076458vkb.3 for ; Fri, 08 Jul 2016 16:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1Skkum1Z3g81Mbggm8iy3dNnOc0MJkuTBOZ9eUj6aHM=; b=unDunxfZq6BAJzxu5nTS75BMvuHIsx71AvjempXuKesExksxNewIR6sdJwEKcTopr8 HXtbUDQ42Rdu9wb+wc7iVmXMw/7ReEbb3DeHG7owM/DvRNmI4yWhQfZXRdJjSCR2GrVj 9HjWeeTarbPi1LeJBygTugCtb+k930PfN7C2Qfs2zH7gotMATT8J18btX27s9o0fLIA/ 68VtBrXXemwzO9vLYW/7Q6LDFfVtv32NObg9Z+LfRgAIbRUmfSjXPz08hli2y8/PdCn7 l1CbYJM74gwLdhOwZ0w0EfDdOcXmHxMk9Hx47F2zMBV4+2RVvrh2gw/OZteXTUpznTS1 Ntxw== 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; bh=1Skkum1Z3g81Mbggm8iy3dNnOc0MJkuTBOZ9eUj6aHM=; b=H1DvVhG6SoK68o16dCdZjG70olIjv0rw5Rj/dnwi+7HN8gO0evcE87LKkK7MkJ+Ei2 r7e/Q5qe+SjfTXhkrnoE+1tCGB2ucBQAQVzMKh6J6EDhMNEBPrYcbMoWHqtsHRTV65zP Zxa4KgjPDYonIca1q9fHw6ti6dEl3lxNlD+fob0hw+iyOcrXFxslVHZTcScoghGRtr7G GISElZ6s4jqE5unii0sheJCELNZUZMqeoUFuhIcLjdKaPoWqxUg5xmSWysPSNQBfoDLj q/Ivi/9VtkNjgCIGx4BHc10tDi84TMnSq26x/boF7b+Bx/NJp7xut6U3UlZa7umsUH0z K87g== X-Gm-Message-State: ALyK8tJB4jbF40641Ii0xm9a1k53kVI4qZ4Qy5G574Rxa3rCUdYUmnDEzrkIfOJYaVFuf+lZvSBpPssUIeEQfw== X-Received: by 10.159.36.22 with SMTP id 22mr64637uaq.105.1468019449131; Fri, 08 Jul 2016 16:10:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:48 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:48 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=001a11352aaaca08cb053727e945 Archived-At: Subject: [Netconf] review request for media type application/yang-patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:10:57 -0000 --001a11352aaaca08cb053727e945 Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-patch media type registration request (was application/yang-patch+xml) Type name: application Subtype name: yang-patch Required parameters: None Optional parameters: None // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with // the actual RFC reference for YANG 1.1, and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to the XML Encoding Rules and Canonical Format for the specific YANG data node type defined in [draft-ietf-netmod-rfc6020bis]. In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize the YANG Patch data structure. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .xml Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no --001a11352aaaca08cb053727e945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised applic= ation/yang-patch media type registration request
(was application= /yang-patch+xml)
      Type name: application

      Subtype name: yang-patch

      Required parameters: None

      Optional parameters: None

     // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
     // the actual RFC reference for YANG 1.1, and remove this note.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // and remove this note

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to the
         XML Encoding Rules and Canonical Format for the specific
         YANG data node type defined in [draft-ietf-netmod-rfc6020bis].
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
     // section number for Security Considerations
     // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
     // RFC number, and remove this note.

      Security considerations: Security considerations related
         to the generation and consumption of RESTCONF messages
         are discussed in Section NN of [RFCXXXX].
         Additional security considerations are specific to the
         semantics of particular YANG data models. Each YANG module
         is expected to specify security considerations for the
         YANG data defined in that module.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"> = // note Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize the YANG Patch data structure. Fragment identifier considerations: The fragment field in the request URI has no defined purpose. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .xml Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no

--001a11352aaaca08cb053727e945-- From nobody Fri Jul 8 16:11:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA20212D925 for ; Fri, 8 Jul 2016 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVymBDOMPU-s for ; Fri, 8 Jul 2016 16:10:57 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D6E12D935 for ; Fri, 8 Jul 2016 16:10:54 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id d67so73621516vkh.1 for ; Fri, 08 Jul 2016 16:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rFppfsO/+g1mVsCO7ms+9a/glq6etmWSKPhxQ2HmbCA=; b=GPPhXdh3L///OTLDtnmbqDlV1i7H+yHN24wQL/C+OXp6moL3g39JGr7qRtzRrDLjiK 21PrMrnnGBWP46ksNrbvKvbynZnjTyA3f1aRaR9cTx/gNdWQCaw1P0eyj3E2KuKiqSBi TSwyu15NH4RAqjiUUTa2QvaplwuYRvEFTsROcZsi1fpn8X1hLTCNxx48kYse2XBnDvqX SXeW5y36B/MjxhwNpDety99fxocfiJv0iuXl/7AfLtkGLN123k/WbtvF3k6VAtSB5EBM rLG+dbb7Ffq8bIJnAdy+oJKek6IC1vGSWthwEo5/l7B2J20I5MMOIssab5Md0ux9x06u Nc7w== 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; bh=rFppfsO/+g1mVsCO7ms+9a/glq6etmWSKPhxQ2HmbCA=; b=cDdWUL3DcGdmT93r4Y3lW70N1e5qTzeibFOCPibe5YY9+znRPucGTUpRpdfgDYi3f2 3QkHI/g6302xbRQVtX7gKchtcIXYCFKS3H1o0zyNc1yeHk2BDm0r+eGNfVSZQUXca025 Wa2EHR68+/psb9/xV1XKwRzNiG6IWoiobu81cxSlZODTftFIRmmIAfWaCbEXm8/+DT4U XT4d9EDjxEH1Klh856eHsEnj4SmROsvd0ldOWyAhK0Z8J6OKChWK5wXAhRmpKaACOXCf JhNs9rrZeEi2tbK6HUFCUcSgYr7oQRUzA4hJpfsFRq68HtjU9n6giMqRFtFUylLCq/ug lJjg== X-Gm-Message-State: ALyK8tIMFX1XwUoHjbH/1bSzR5W12I5OKr2Hv/GeMJD3Dn0OGGatgv293PDoi7ACdyWUwzNSUWiBsZV2Igo7Ug== X-Received: by 10.31.9.65 with SMTP id 62mr3890582vkj.89.1468019453736; Fri, 08 Jul 2016 16:10:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Fri, 8 Jul 2016 16:10:53 -0700 (PDT) From: Andy Bierman Date: Fri, 8 Jul 2016 16:10:53 -0700 Message-ID: To: Netconf , media-types@iana.org Content-Type: multipart/alternative; boundary=001a11440b64104ba1053727ea78 Archived-At: Subject: [Netconf] review request for media type application/yang-patch+json X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:10:59 -0000 --001a11440b64104ba1053727ea78 Content-Type: text/plain; charset=UTF-8 Hi, Here is the revised application/yang-patch+json media type registration request Type name: application Subtype name: yang-patch+json Required parameters: None Optional parameters: None // RFC Ed.: replace draft-ietf-netmod-yang-json with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace draft-ietf-netmod-yang-metadata with // the actual RFC reference for JSON Encoding of YANG Data, // and remove this note. // RFC Ed.: replace 'XXXX' with the real RFC number, // and remove this note Encoding considerations: 8-bit Each conceptual YANG data node is encoded according to [draft-ietf-netmod-yang-json]. A data annotation is encoded according to [draft-ietf-netmod-yang-metadata] In addition, the "yang-patch" YANG data template found in [RFCXXXX] defines the structure of a YANG Patch request. // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the // section number for Security Considerations // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual // RFC number, and remove this note. Security considerations: Security considerations related to the generation and consumption of RESTCONF messages are discussed in Section NN of [RFCXXXX]. Additional security considerations are specific to the semantics of particular YANG data models. Each YANG module is expected to specify security considerations for the YANG data defined in that module. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Interoperability considerations: [RFCXXXX] specifies the format of conforming messages and the interpretation thereof. // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Published specification: RFC XXXX Applications that use this media type: Instance document data parsers used within a protocol or automation tool that utilize the YANG Patch data structure. Fragment identifier considerations: The syntax and semantics of fragment identifiers are the same as specified for the "application/json" media type. Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): .json Macintosh file type code(s): "TEXT" // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Person & email address to contact for further information: See Authors' Addresses section of [RFCXXXX]. Intended usage: COMMON Restrictions on usage: N/A // RFC Ed.: replace XXXX with actual RFC number and remove this // note. Author: See Authors' Addresses section of [RFCXXXX]. Change controller: Internet Engineering Task Force (mailto:iesg&ietf.org). Provisional registration? (standards tree only): no --001a11440b64104ba1053727ea78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the revised appl= ication/yang-patch+json media type registration request


=
= Type name: application
      Subtype name: yang=
-patch+json

      Required parameters: None

      Optional parameters: None

     // RFC Ed.: replace draft-ietf-netmod-yang-json with
     // the actual RFC reference for JSON Encoding of YANG Data,
     //  and remove this note.

     // RFC Ed.: replace draft-ietf-netmod-yang-metadata with
     // the actual RFC reference for JSON Encoding of YANG Data,
     //  and remove this note.

     // RFC Ed.: replace 'XXXX' with the real RFC number,
     // and remove this note

      Encoding considerations: 8-bit
         Each conceptual YANG data node is encoded according to
         [draft-ietf-netmod-yang-json]. A data annotation is
         encoded according to [draft-ietf-netmod-yang-metadata]
         In addition, the "yang-patch" YANG data template found
         in [RFCXXXX] defines the structure of a YANG Patch request.

     // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
     // section number for Security Considerations
     // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
     // RFC number, and remove this note.

      Security considerations: Security considerations related
         to the generation and consumption of RESTCONF messages
         are discussed in Section NN of [RFCXXXX].
         Additional security considerations are specific to the
         semantics of particular YANG data models. Each YANG module
         is expected to specify security considerations for the
         YANG data defined in that module.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Interoperability considerations: [RFCXXXX] specifies the format
         of conforming messages and the interpretation thereof.

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Published specification: RFC XXXX

      Applications that use this media type: Instance document
        data parsers used within a protocol or automation tool
        that utilize the YANG Patch data structure.

      Fragment identifier considerations: The syntax and semantics
         of fragment identifiers are the same as specified for the
        "application/json" media type.

      Additional information:

        Deprecated alias names for this type: N/A
        Magic number(s): N/A
        File extension(s): .json
        Macintosh file type code(s): "TEXT"

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Person & email address to contact for further information: See
         Authors' Addresses section of [RFCXXXX].

      Intended usage: COMMON

      Restrictions on usage: N/A

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

      Author: See Authors' Addresses section of [RFCXXXX].

      Change controller: Internet Engineering Task Force
         (mailto:iesg&ietf.org).

      Provisional registration? (standards tree only): no

--001a11440b64104ba1053727ea78-- From nobody Sat Jul 9 14:00:22 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4C312B019; Sat, 9 Jul 2016 14:00:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160709210021.2403.11326.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2016 14:00:21 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-ssh-client-server-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 21:00:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : SSH Client and Server Models Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-ssh-client-server-00.txt Pages : 20 Date : 2016-07-08 Abstract: This document defines two YANG modules, one defines groupings for a generic SSH client and the other defines groupings for a generic SSH server. It is intended that these groupings will be used by applications using the SSH protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 9 14:00:56 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E32812D177; Sat, 9 Jul 2016 14:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160709210052.2468.82064.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2016 14:00:52 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-netconf-client-server-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 21:00:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : NETCONF Client and Server Models Authors : Kent Watsen Gary Wu Juergen Schoenwaelder Filename : draft-ietf-netconf-netconf-client-server-00.txt Pages : 38 Date : 2016-07-08 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 9 20:20:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B112B007 for ; Sat, 9 Jul 2016 20:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m693nxA1g3UR for ; Sat, 9 Jul 2016 20:20:18 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C268212B034 for ; Sat, 9 Jul 2016 20:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6ht9JOq2jZX8j1HC+KdT37/9WHyluulGd/k/vTi+X78=; b=kueegbvQNMQRgVcInhOqk8DcvbGLbL4fyAl0obfo21b0HFlneeaXZ0sReq5FxFErgf8H6F2q4DSN5yoBs710+Dc889Re964IN6fKYayb2W8jb2TU44131JfBhPf3TrwAlleBv0KEdEkNk7IAx2gHHMIyNBM5zn0LaPr5SAzYy5Y= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Sun, 10 Jul 2016 03:20:15 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.024; Sun, 10 Jul 2016 03:20:15 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: regarding all the new client/server model drafts Thread-Index: AQHR2ln6zpCdQTDSs0+5IKtZ13D65w== Date: Sun, 10 Jul 2016 03:20:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: ec169ab6-09cb-44cb-f1dd-08d3a8711cc9 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:8GW+uBkysWYSlUtiardtKjIpIgFBqEcObqLoszusBnbO58G9NRna/DsGxZJXIH8vxQ8wq8sTg4mPAYhXj3s4Z44BvOp8T/VcN6BtdVvwSHjeP7KIfY1dF3fNEIXqWx3363c/pjNtJym/vb/c26TG+jAzqjKe23VHpOv/S3Gj2LXihWOBORbuHCdrMps9kgLBk+UIYmfjg4wNSptOHTa2qBj06dpR4DlSKcMm+NxKkDdKuX3Oah6MovNf16LNFn7yVoxvXsgwV+UP7rgiCzFvUTzLKJD40SG0BOKsoZEVGXTfd60K8Uvw68+aguFxd9+n19HpqyvTRdrTk/ENhhkWNA==; 5:0s/4BaiRmISqFBUtlrmuL+akREllbT0yPS8MNc0O/tCrh2UrDkkscLJ8RLEDskOZ/NcV4M/42k6XP3qvO9LRoADDQ4rI2lkN6q8eQLsO0Q4QJATKR3EV3wF3iDnBDPpWFLYPoEvKMN9WQRvd17XTeQ==; 24:nl2CfaIce/Q2CYPpX/2jCoq1sQ5nY2ullN5aDiVzVrrH1+u6yP9W97cgnyfvrE9XIsmx234ZqUnCcSAQGewS46tW1FhwUx8r1/j277iiCRY=; 7:nbyCUzsBELliB0TpWFsu5YymBhVschl/yL55g/uvwoT43KAFXrDp1XrBlh1LOPXXBdckn6JpLuj52NCBYHk+0EBGEP+yoQhsibqyv4mppNPKYZEzrjz0YkdCjPebHrWwpMWKjxSQKkYBgTrpvEhRVRMI1qDuggghUwfASIfA2HpVUoga0XpyJ5WFjdY5/WgscHv6OD5KKyMIi4OxBJOBcjZtfUjBS5Tt1lPJHN9TQx4RZlbWguIyUU4gG3T9Vd18 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0999136621 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(83716003)(99286002)(19300405004)(10400500002)(122556002)(5002640100001)(7736002)(101416001)(86362001)(4001350100001)(105586002)(16236675004)(82746002)(586003)(11100500001)(33656002)(2351001)(87936001)(229853001)(19625215002)(54356999)(107886002)(50986999)(189998001)(77096005)(92566002)(110136002)(2906002)(2900100001)(15975445007)(36756003)(19580395003)(450100001)(66066001)(5640700001)(8936002)(102836003)(2501003)(68736007)(3280700002)(106356001)(8676002)(1730700003)(81156014)(81166006)(3660700001)(97736004)(106116001)(7846002)(83506001)(6116002)(3846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B8BE327A8EFF41B0A35F68FF2847F593junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2016 03:20:15.6138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: [Netconf] regarding all the new client/server model drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 03:20:22 -0000 --_000_B8BE327A8EFF41B0A35F68FF2847F593junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBcyBwZXIgZGVjaXNpb24sIHRoZSBzZXJ2ZXItbW9kZWwgZHJhZnQgaGFzIGJlZW4gc3BsaXQg aW50byBmaXZlIGRyYWZ0cy4gIFNwbGl0dGluZyBpdCBvdXQgaW50byBzbyBtYW55IGRyYWZ0cyB0 b29rIGEgc3VycHJpc2luZ2x5IGxvbmcgYW1vdW50IG9mIHRpbWUuICAgVGhlIHJlYWwgaGlnaGxp Z2h0LCBJIHRoaW5rLCBpcyB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSBuZXcg4oCcY2xpZW504oCd IG1vZGVscywgYXMgYmVmb3JlIHdlIG9ubHkgaGFkIHNlcnZlciBtb2RlbHMuICBHYXJ5IFd1IGZy b20gQ2lzY28gaGFzIGhlbHBlZCBvdXQgb24gdGhlIGNsaWVudCBtb2RlbHMuICBUaGUgY2xpZW50 IG1vZGVscyBoYXZlIGJlZW4gZGlmZmljdWx0IHRvIG5haWwgZG93biBhbmQsIHRvIGJlIGhvbmVz dCwgd2hhdCB3ZSBoYXZlIG5vdyBpc27igJl0IHBlcmZlY3QuICBTYWRseSwgZHVlIHRvIHJ1bm5p bmcgb3V0IG9mIHRpbWUsIHdlIG9ubHkgZ290IHRoZSBTU0gtY2xpZW50IGFuZCBORVRDT05GLWNs aWVudCBtb2RlbHMgZmx1c2hlZCBvdXQuICBUaGUgVExTLWNsaWVudCBhbmQgUkVTVENPTkYtY2xp ZW50IG1vZGVscyBhcmUgbm90IGN1cnJlbnRseSBmbHVzaGVkIG91dC4gIElmIGxvb2tpbmcgZm9y IHRoZSBUTFMvUkVTVENPTkYgbW9kZWxzIG5vdywgcGxlYXNlIGltYWdpbmUgdGhlbSBiZWluZyB2 ZXJ5IHNpbWlsYXIgdG8gdGhlIFNTSC9ORVRDT05GIG1vZGVscywgYXMgdGhleeKAmWQgZm9sbG93 IHRoZSBzYW1lIHBhdHRlcm4uDQoNClRoYW5rcywNCktlbnQNCg0K --_000_B8BE327A8EFF41B0A35F68FF2847F593junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <858237C755A1CA4BB9EC50C4CA86C4A7@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QXMgcGVyIGRlY2lzaW9uLCB0aGUgc2VydmVyLW1vZGVsIGRyYWZ0 IGhhcyBiZWVuIHNwbGl0IGludG8gZml2ZSBkcmFmdHMuJm5ic3A7IFNwbGl0dGluZyBpdCBvdXQg aW50byBzbyBtYW55IGRyYWZ0cyB0b29rIGEgc3VycHJpc2luZ2x5IGxvbmcgYW1vdW50IG9mIHRp bWUuJm5ic3A7Jm5ic3A7IFRoZSByZWFsIGhpZ2hsaWdodCwgSSB0aGluaywgaXMgdGhlIGludHJv ZHVjdGlvbiBvZg0KIHRoZSBuZXcg4oCcY2xpZW504oCdIG1vZGVscywgYXMgYmVmb3JlIHdlIG9u bHkgaGFkIHNlcnZlciBtb2RlbHMuJm5ic3A7IEdhcnkgV3UgZnJvbSBDaXNjbyBoYXMgaGVscGVk IG91dCBvbiB0aGUgY2xpZW50IG1vZGVscy4mbmJzcDsgVGhlIGNsaWVudCBtb2RlbHMgaGF2ZSBi ZWVuIGRpZmZpY3VsdCB0byBuYWlsIGRvd24gYW5kLCB0byBiZSBob25lc3QsIHdoYXQgd2UgaGF2 ZSBub3cgaXNu4oCZdCBwZXJmZWN0LiZuYnNwOyBTYWRseSwgZHVlIHRvIHJ1bm5pbmcgb3V0IG9m IHRpbWUsDQogd2Ugb25seSBnb3QgdGhlIFNTSC1jbGllbnQgYW5kIE5FVENPTkYtY2xpZW50IG1v ZGVscyBmbHVzaGVkIG91dC4mbmJzcDsgVGhlIFRMUy1jbGllbnQgYW5kIFJFU1RDT05GLWNsaWVu dCBtb2RlbHMgYXJlIG5vdCBjdXJyZW50bHkgZmx1c2hlZCBvdXQuJm5ic3A7IElmIGxvb2tpbmcg Zm9yIHRoZSBUTFMvUkVTVENPTkYgbW9kZWxzIG5vdywgcGxlYXNlIGltYWdpbmUgdGhlbSBiZWlu ZyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIFNTSC9ORVRDT05GIG1vZGVscywgYXMgdGhleeKAmWQNCiBm b2xsb3cgdGhlIHNhbWUgcGF0dGVybi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+S2VudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_B8BE327A8EFF41B0A35F68FF2847F593junipernet_-- From nobody Mon Jul 11 09:52:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8212D5AE; Mon, 11 Jul 2016 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhnDmqyuOXEX; Mon, 11 Jul 2016 09:52:24 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED36E12D532; Mon, 11 Jul 2016 09:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=345943; q=dns/txt; s=iport; t=1468255943; x=1469465543; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=WiDaGYupgZs4PqE4QLl72YYMhSgCM2TYGq8oAvqV4wE=; b=aZ5QW3u2ciJxCNgmuulUYH5BSixU48DGylVcFGzoBA5wXdW/jZB4dpOf OHdqeKF3x3F3/H9eJfyOfYe6yCvJiLqh2+SO7fWgxzhRM4HdFNZ4LrsSG Q5yUkVS5dJi/yVkVaQWLAxa2zJkR2BVg4gz+LvLQDknIrvM3QzCxqQMGd 8=; X-Files: pfdhgdlfgpjnekof.png : 224929 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBACSzYNX/xbLJq3IdAICAQ X-IronPort-AV: E=Sophos;i="5.28,347,1464652800"; d="png'150?scan'150,208,217,150";a="638492393" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2016 16:52:20 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6BGqHJY003664; Mon, 11 Jul 2016 16:52:17 GMT References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> From: Benoit Claise To: "draft-ietf-netconf-yang-patch@ietf.org" X-Forwarded-Message-Id: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> Message-ID: <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> Date: Mon, 11 Jul 2016 18:52:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> Content-Type: multipart/alternative; boundary="------------D8BF43D19305363030A1D58D" Archived-At: Cc: NETCONF Subject: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:52:27 -0000 This is a multi-part message in MIME format. --------------D8BF43D19305363030A1D58D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Now that RESTCONF progressed, here is my draft-ietf-netconf-yang-patch-10 AD review. - I see one issue at https://github.com/netconf-wg/yang-patch/issues. Is this integrated? - This is a comment for the RESCONF draft: https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 OLD: Please see [I-D.ietf-netconf-yang-patch ] for an alternate media-type supporting the ability to delete child resources. The YANG Patch Media Type allows multiple sub-operations (e.g., merge, delete) within a single PATCH operation. NEW (change . by :): Please see [I-D.ietf-netconf-yang-patch ] for an alternate media-type supporting the ability to delete child resources: The YANG Patch Media Type allows multiple sub-operations (e.g., merge, delete) within a single PATCH operation. - Editorial OLD: An "ordered edit list" approach is needed to provide client developers with more precise client control of the edit procedure than existing mechanisms. NEW: An "ordered edit list" approach is needed to provide client developers with more precise client control of the edit procedure than existing mechanisms [RESTCONF]. Btw, is this more precise? Or it offers more capabilities? It's only when reading through the doc that we discover the advantages versus the plain patch - ordered collection of edits, while https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 is for a single edit - an edit operation (create, delete, insert, merge, move, replace, remove), while https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 is for create or update - patch-id - etc... I've been missing a section about the advantages compared to the plain PATCH somewhere at the beginning of the doc. Btw, I guess that nothing prevents a RESTCONF server to support simultaneously the plain PATCH ( https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6) and the PATCH in this document? However, doing so, would provide a useless audit log, since the plain PATCH doesn't have a patch-id leaf patch-id { type string; description "An arbitrary string provided by the client to identify the entire patch. This value SHOULD be present in any audit logging records generated by the server for the patch. Error messages returned by the server pertaining to this patch will be identified by this patch-id value."; } Worth writing some text about it? - Terminology Same remark as for the RESTCONF draft v13: RESTCONF server, NETCONF server, server. "Server" according to the terminology section is the RFC6241 definition, so server = NETCONF server. A "YANG Patch" is an ordered list of edits that are applied to the target datastore by the server So this sentence contradicts: It may be possible to use YANG Patch with other protocols besides RESTCONF. This is outside the scope of this document. Please apply the same changes as for RESTCONF o RESTCONF client: a client which implements the RESTCONF protocol. Also called "client". o RESTCONF server: a server which implements the RESTCONF protocol. Also called "server". - Terminology: 1.1.2 . HTTP The following terms are defined in [RFC7230 ]: o header field o message body o method o query o request URI Throughout the doc.: message body => message-body https://tools.ietf.org/html/draft-ietf-netconf-restconf-14 mentions: - header and not header field - message-body and not message body - method referenced from RFC7231, not RFC7230 - Inconsistencies between the RESTCONF and PATCH terminology: draft-ietf-netconf-yang-patch refers to the RESTCONF "YANG data template" definition. However, in the RESTCONF doc: YANG data template: a schema for modeling a conceptual data structure in an encoding-independent manner. It is defined with the "yang-data" extension, found inSection 8 ._It has a representation with the media-type "application/yang-data+xml" or "application/yang-data+json"._ draft-ietf-netconf-yang-patch mentions: o YANG Patch: a conceptual edit request using the "yang-patch"_YANG data template_, defined inSection 3 . In HTTP, refers to a PATCH method where a representation_uses either the media type "application/yang-patch+xml" or "application/yang-patch+json"._ Same remark for: o YANG Patch Status: a conceptual edit status response using the YANG "yang-patch-status" YANG data template, defined inSection 3 . In HTTP, refers to a response message for a PATCH method, where it has a representation with either the media type "application/ yang-data+xml" or "application/yang-data+json". - 1.1.6. Tree Diagrams Should be renamed to "tree diagram notations" - Is the YANG Patch valid for both YANG 1.0 and YANG 1.1? RESTCONF is: This document defines an HTTP [RFC7230 ] based protocol called RESTCONF, for configuring data defined in YANG version 1 [RFC6020 ] or YANG version 1.1 [I-D.ietf-netmod-rfc6020bis ], using the datastore concepts defined in NETCONF [RFC6241 ]. Apparently, the YANG patch is only valid for YANG 1.1: There is a need for standard mechanisms to patch datastores defined in [RFC6241 ], which contain conceptual data that conforms to schema specified with YANG [I-D.ietf-netmod-rfc6020bis ]. - Section 2.1 The YANG Patch operation uses the RESTCONF target resource URI to identify the resource that will be patched. This can be the datastore resource itself, i.e., "{+restconf}/data", or it can be a configuration data resource within the datastore resource, e.g., {+restconf/data/ietf-interfaces:interfaces". What would be an example of the datastore resource itself? - I received this feedback, directly sent to me. 2.2 . yang-patch Input A data element representing the YANG Patch is sent by the client to specify the edit operation request. When used with the HTTP PATCH method, this data is identified by the YANG Patch media type. What does data element mean? Where is its definition? 2.2. yang-patch Input Should be yang-patch request or something that someone not familiar with the netconf RPC concept can related to in the HTTP world which this I-D is for. 2.3. yang-patch-status Output Should be yang-patch response. Same reason as above. - section 2.5 | remove | remove a data resource if it already exists or no | | | error | +---------------+---------------------------------------------------+ NEW: | remove | remove a data resource if it already exists or no | | | error | +---------------+---------------------------------------------------+ First, after reading further below, “or no error†could be removed or replaced with “if no errorâ€. - modify/replace the entire datastore Each YANG patch edit specifies one edit operation on the target data node. The set of operations is aligned with the NETCONF edit operations, but also includes some new operations. +---------------+---------------------------------------------------+ | Operation | Description | +---------------+---------------------------------------------------+ | create | create a new data resource if it does not already | | | exist or error | | delete | delete a data resource if it already exists or | | | error | | insert | insert a new user-ordered data resource | | merge | merge the edit value with the target data | | | resource; create if it does not already exist | | move | re-order the target data resource | | replace | replace the target data resource with the edit | | | value | | remove | remove a data resource if it already exists or no | | | error | +---------------+---------------------------------------------------+ And, in section 2.1 This can be the datastore resource itself, i.e., "{+restconf}/data", or it can be a configuration data resource within the datastore resource, e.g., {+restconf/data/ietf-interfaces:interfaces". [this relates to this email thread "[Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ?] When I look at "replace" above, I'm not sure whether we can modify/replace the entire datastore. So basically replacing the entire config from a router. */ /*I always thought it was only possible with NETCONF, with the support of the :url capability. So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I was thinking that "A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable." could only be fulfilled with NETCONF. Now, I'm confused. - Section 2.2 and 2.3 YANG Tree Diagram For "yang-patch" Container*/ /*s/For/for YANG Tree Diagram For "yang-patch-status" Container *//*s/For/for Not sure yet how/if we should document tree for YANG modules composed of groupings only. Currently in discussion with the YANG doctors. - Section 2.6 The server will save the running datastore to non-volatile storage if it supports non-volatile storage, and if the running datastore contents have changed. This will be done in an implementation- specific manner. You might to add that this is a RESTCONF feature, not a YANG PATCH one. Indeed, from https://tools.ietf.org/html/draft-ietf-netconf-restconf-15, section 3.4 Each RESTCONF edit of a datastore resource is saved to non-volatile storage by the server, if the server supports non-volatile storage of configuration data. What is confusing here is: what does "This will be done in an implementation-specific manner." add in draft-ietf-netconf-yang-patch-10 compared to RESTCONF. Should this sentence be part of draft-ietf-netconf-restconf, and removed from here? - leaf comment { type string; description "An arbitrary string provided by the client to describe the entire patch. This value SHOULD be present in any audit logging records generated by the server for the patch."; I don't understand why it's not a MUST. Is this because this field is optional? So if it's not in the audit logging, we don't know if it's because the field is empty, or because someone decided not to include it. Do you want to say: If populated, this value MUST be present in any audit logging records generated by the server for the patch. - I'm not clear on the atomicity rules container yang-patch { description "Represents a conceptual sequence of datastore edits, called a patch. Each patch is given a client-assigned patch identifier. Each edit MUST be applied in ascending order, and all edits MUST be applied. If any errors occur, then the target datastore MUST NOT be changed by the patch operation. In https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4, if "edit2" fails, should edit1 be reverted? If, by patch operation, you mean "leaf operation", then the applied change by edit1 should remain, right? If so, if edit2 fails, would edit3 be applied? Reading further, I see in section 5: If the entire YANG Patch request cannot be completed, then no configuration changes to the system are done. Now, I'm confused. An additional example would be useful (only edit2 fails). Assuming the sentence in section 5 is right ... Since there are no candidate datastores in RESTCONF, is this realistic to "test" edit1, edit2, edit3 part of the https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4 in order to populate the potential error message, and to revert the command if there is an error message? And I see this diff between version 8 and 9. Surprised that, if there is any error, it's not a MUST to return the "yang-patch-status" message? Maybe I missed the discussion on the mailing list. Feel free to let me know. - Section 5. It may be possible to use YANG Patch with other protocols besides RESTCONF, which is outside the scope of this document. Is a repeat from the intro. - Editorial OLD case global-errors { uses rc:errors; description "This container will be present if global errors unrelated to a specific edit occurred."; } NEW case global-errors { uses rc:errors; description "This container will be present if global errors are unrelated to a specific edit occurred."; } Regards, Benoit (OPS AD) --------------D8BF43D19305363030A1D58D Content-Type: multipart/related; boundary="------------EA422DC7FAB5A2E96AB6EB8B" --------------EA422DC7FAB5A2E96AB6EB8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Now that RESTCONF progressed, here is my draft-ietf-netconf-yang-patch-10 AD review.


- I see one issue at https://github.com/netconf-wg/yang-patch/issues. Is this integrated?

- This is a comment for the RESCONF draft: https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6

OLD:
   Please see
   [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting
   the ability to delete child resources.  The YANG Patch Media Type
   allows multiple sub-operations (e.g., merge, delete) within a single
   PATCH operation.
NEW (change . by :):
   Please see
   [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting
   the ability to delete child resources: The YANG Patch Media Type
   allows multiple sub-operations (e.g., merge, delete) within a single
   PATCH operation.

- Editorial
OLD:
   An "ordered edit
   list" approach is needed to provide client developers with more
   precise client control of the edit procedure than existing
   mechanisms.

NEW:
   An "ordered edit
   list" approach is needed to provide client developers with more
   precise client control of the edit procedure than existing
   mechanisms [RESTCONF].
Btw, is this more precise? Or it offers more capabilities?
It's only when reading through the doc that we discover the advantages versus the plain patch
- ordered collection of edits, while https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 is for a single edit
- an edit operation (create, delete, insert, merge, move, replace, remove), while https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6
  is for create or update
- patch-id
- etc...
I've been missing a section about the advantages compared to the plain PATCH somewhere at the beginning of the doc.

Btw, I guess that nothing prevents a RESTCONF server to support simultaneously the plain PATCH ( https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6) and the PATCH in this document? However, doing so, would provide a useless audit log, since the plain PATCH doesn't have a patch-id
      leaf patch-id {
           type string;
           description
             "An arbitrary string provided by the client to identify
              the entire patch.  This value SHOULD be present in any
              audit logging records generated by the server for the
              patch. Error messages returned by the server pertaining
              to this patch will be identified by this patch-id value.";
         }
Worth writing some text about it?
   

- Terminology
Same remark as for the RESTCONF draft v13: RESTCONF server, NETCONF server, server.
"Server" according to the terminology section is the RFC6241 definition, so server = NETCONF server.
A "YANG Patch" is an ordered list of edits that are applied to the
   target datastore by the server
So this sentence contradicts: 
   It may be possible to use YANG Patch with other protocols besides
   RESTCONF.  This is outside the scope of this document.
Please apply the same changes as for RESTCONF
   o  RESTCONF client: a client which implements the RESTCONF protocol.
      Also called "client".

   o  RESTCONF server: a server which implements the RESTCONF protocol.
      Also called "server".

- Terminology:
1.1.2.  HTTP


   The following terms are defined in [RFC7230]:

   o  header field

   o  message body

   o  method

   o  query

   o  request URI


Throughout the doc.: message body => message-body
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14 mentions:
	- header and not header field
	- message-body and not message body
	- method referenced from RFC7231, not RFC7230
- Inconsistencies between the RESTCONF and PATCH terminology:
draft-ietf-netconf-yang-patch refers to the RESTCONF "YANG data template" definition.

However, in the RESTCONF doc: 
      YANG data template: a schema for modeling a conceptual data
      structure in an encoding-independent manner.  It is defined with
      the "yang-data" extension, found in Section 8.  It has a
      representation with the media-type "application/yang-data+xml" or
      "application/yang-data+json".
draft-ietf-netconf-yang-patch mentions:
      o  YANG Patch: a conceptual edit request using the "yang-patch" YANG
      data template, defined in Section 3.  In HTTP, refers to a PATCH
      method where a representation uses either the media type
      "application/yang-patch+xml" or "application/yang-patch+json".

Same remark for:
   o  YANG Patch Status: a conceptual edit status response using the
      YANG "yang-patch-status" YANG data template, defined in Section 3.
      In HTTP, refers to a response message for a PATCH method, where it
      has a representation with either the media type "application/
      yang-data+xml" or "application/yang-data+json".

- 1.1.6.  Tree Diagrams
Should be renamed to "tree diagram notations"


- Is the YANG Patch valid for both YANG 1.0 and YANG 1.1?
RESTCONF is:
 This document defines an HTTP [RFC7230] based protocol called
   RESTCONF, for configuring data defined in YANG version 1 [RFC6020] or
   YANG version 1.1 [I-D.ietf-netmod-rfc6020bis], using the datastore
   concepts defined in NETCONF [RFC6241].
Apparently, the YANG patch is only valid for YANG 1.1:
  There is a need for standard mechanisms to patch datastores defined
   in [RFC6241], which contain conceptual data that conforms to schema
   specified with YANG [I-D.ietf-netmod-rfc6020bis].
- Section 2.1 
   The YANG Patch operation uses the RESTCONF target resource URI to
   identify the resource that will be patched.  This can be the
   datastore resource itself, i.e., "{+restconf}/data", or it can be a
   configuration data resource within the datastore resource, e.g.,
   {+restconf/data/ietf-interfaces:interfaces".
What would be an example of the datastore resource itself?
- I received this feedback, directly sent to me.

2.2.  yang-patch Input

   A data element representing the YANG Patch is sent by the client to    specify the edit operation request.  When used with the HTTP PATCH    method, this data is identified by the YANG Patch media type.

What does data element mean?  Where is its definition?

2.2.  yang-patch Input
Should be yang-patch request or something that someone not familiar with the netconf RPC concept can related to in the HTTP world which this I-D is for.

2.3.  yang-patch-status Output
Should be yang-patch response.  Same reason as above.

-
section 2.5

   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   +---------------+---------------------------------------------------+

NEW:

   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   +---------------+---------------------------------------------------+

First, after reading further below, “or no error†could be removed or replaced with “if no errorâ€.

- modify/replace the entire datastore 

   Each YANG patch edit specifies one edit operation on the target data
   node.  The set of operations is aligned with the NETCONF edit
   operations, but also includes some new operations.

   +---------------+---------------------------------------------------+
   | Operation     | Description                                       |
   +---------------+---------------------------------------------------+
   | create        | create a new data resource if it does not already |
   |               | exist or error                                    |
   | delete        | delete a data resource if it already exists or    |
   |               | error                                             |
   | insert        | insert a new user-ordered data resource           |
   | merge         | merge the edit value with the target data         |
   |               | resource; create if it does not already exist     |
   | move          | re-order the target data resource                 |
   | replace       | replace the target data resource with the edit    |
   |               | value                                             |
   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   +---------------+---------------------------------------------------+
And, in section 2.1
   This can be the
   datastore resource itself, i.e., "{+restconf}/data", or it can be a
   configuration data resource within the datastore resource, e.g.,
   {+restconf/data/ietf-interfaces:interfaces".

[this relates to this email thread "[Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ?]
When I look at "replace" above, I'm not sure whether we can modify/replace the entire datastore. So basically replacing the entire config from a router.
I always thought it was only possible with NETCONF, with the support of the :url capability.
So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I was thinking that "A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable." could only be fulfilled with NETCONF.
Now, I'm confused.

- Section 2.2 and 2.3
YANG Tree Diagram For "yang-patch" Container
    s/For/for
YANG Tree Diagram For "yang-patch-status" Container
    s/For/for

Not sure yet how/if we should document tree for YANG modules composed of groupings only. Currently in discussion with the YANG doctors.

- Section 2.6
   The server will save the running datastore to non-volatile storage if
   it supports non-volatile storage, and if the running datastore
   contents have changed.  This will be done in an implementation-
   specific manner.
You might to add that this is a RESTCONF feature, not a YANG PATCH one.
Indeed, from https://tools.ietf.org/html/draft-ietf-netconf-restconf-15, section 3.4
 
Each RESTCONF edit of a datastore resource is
saved to non-volatile storage by the server, if the server supports
non-volatile storage of configuration data.
What is confusing here is: what does "This will be done in an implementation-specific manner." add in draft-ietf-netconf-yang-patch-10 compared to RESTCONF.
Should this sentence be part of draft-ietf-netconf-restconf, and removed from here?

- 
leaf comment {
           type string;
           description
             "An arbitrary string provided by the client to describe
              the entire patch.  This value SHOULD be present in any
              audit logging records generated by the server for the
              patch.";

I don't understand why it's not a MUST. Is this because this field is optional?
So if it's not in the audit logging, we don't know if it's because the field is empty, or because someone decided not to include it.
Do you want to say: If populated, this value MUST be present in any audit logging records generated by the server for the patch.

- I'm not clear on the atomicity rules
       container yang-patch {
         description
           "Represents a conceptual sequence of datastore edits,
            called a patch. Each patch is given a client-assigned
            patch identifier. Each edit MUST be applied
            in ascending order, and all edits MUST be applied.
            If any errors occur, then the target datastore MUST NOT
            be changed by the patch operation.

In https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4, if "edit2" fails, should edit1 be reverted?
If, by patch operation, you mean "leaf operation", then the applied change by edit1 should remain, right? If so, if edit2 fails, would edit3 be applied?
Reading further, I see in section 5:
   If the entire YANG Patch
   request cannot be completed, then no configuration changes to the
   system are done.
Now, I'm confused. An additional example would be useful (only edit2 fails).
Assuming the sentence in section 5 is right ... Since there are no candidate datastores in RESTCONF, is this realistic to "test" edit1, edit2, edit3 part of the https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4 in order to populate the potential error message, and to revert the command if there is an error message?

And I see this diff between version 8 and 9. 
Surprised that, if there is any error, it's not a MUST to return the "yang-patch-status" message? Maybe I missed the discussion on the mailing list. Feel free to let me know. - Section 5. 
   It may be possible to use YANG Patch with other protocols besides
   RESTCONF, which is outside the scope of this document.
Is a repeat from the intro. - Editorial OLD 
           case global-errors {
             uses rc:errors;
             description
               "This container will be present if global
                errors unrelated to a specific edit occurred.";
           }
NEW
           case global-errors {
             uses rc:errors;
             description
               "This container will be present if global
                errors are unrelated to a specific edit occurred.";
           }
Regards, Benoit (OPS AD)
--------------EA422DC7FAB5A2E96AB6EB8B Content-Type: image/png; name="pfdhgdlfgpjnekof.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="pfdhgdlfgpjnekof.png" iVBORw0KGgoAAAANSUhEUgAAB/QAAAHdCAIAAACMotZgAAAgAElEQVR4nOzdaVwTWb4//r53 7vx/98703LnTM6OJ2m1ru3W3a6vtviuigAuCoCiKuKCgIogiqwiIqCCKiCigKBFXFBERNxBF EWVxgewhC2Sn2EG21P9BIAmLIjQKbX/eL56QOnXOt05VonyS1PmKBAAAAAAAAAAAAACA35Wv iouLCQAAAAAA6DEqKiq6+88EAAAAAADo6RDuAwAAAAD0LAj3AQAAAACgXQj3AQAAAAB6FoT7 AAAAAADQLoT7AAAAAAA9C8J9AAAAAABoF8J9AAAAAICeBeE+AAAAAAC0C+E+AAAAAEDPgnAf AAAAAADahXAfAAAAAKBnQbgPAAAAAADtQrgPAAAAANCzINwHAAAAAIB2IdwHAAAAAOhZEO4D AAAAAEC7EO4DAAAAAPQsCPcBAAAAAKBdCPcBAAAAAHoWhPsAAAAAANAuhPsAAAAAAD0Lwn0A AAAAAGgXwn0AAAAAgJ4F4T4AAAAAALQL4T4AAAAAQM+CcB8AAAAAANqFcB8AAAAAoGdBuA8A AAAAAO1CuA8AAAAA0LMg3AcAAAAAgHYh3AcAAAAA6FkQ7gMAAAAAQLsQ7gMAAAAA9CwI9wEA AAAAoF0I9wEAAAAAehaE+wAAAAAA0K6v+EWFHIWwW36kRfLu/rsJAAAAAKDHQbgPAAAAAADt +moVN2ghy7tbfh5Is7r77yYAAAAAgB4H4T4AAAAAALTrK0O270SGc7f8JEoyuvvvJgAAAACA HgfhPgAAAAAAtAvhPgAAAABAz4JwHwAAAAAA2oVwHwAAAACgZ0G4DwAAAAAA7UK4D18AqVjI 43F4fAmhLOruWgAAAAB+M4T78EdSV1dTTkgkRHntu7rurgUAAADgdwXhPnwBEqM8VlrMXWV3 hRBKu7sWAAAAgN8M4T78kXA5LwOs+n1rdextKr+7awEAAAD4XdGG+/q8Y85FOUlluanluanl ucmlaVflYfNYrp0J7tkB8woeXS19k1ze2Jv2pyzjkuzSZobzNIT7f3jcR7RzHiv0F5nqO19J zuI2PioXEdmR/lstTfT19fX1F5laOF8RaDa+R9zJHQsMxhhanicEkk9eNgAAAMCn1rlwX5Tg 52dvbtTE+mjyI2ZJJ/9KECXQ/OwtjVoxtjSyOZfMV3a2X/hyVCvyWVE2NquNjeyPhyaytBtk aSlRntZNl4z98Xu6G9vCZDzbu+Q//7Rkf/Z9zqetGQAAAOAL0xjuG+SHuinTUqsLnxQ9uqS4 H6F4FV8iELzLDpeGLePs7XC4zzmxUM7Pryt6VfrihuJ+hOanlJ9RLckrTfZkOM/s1nBfmH3v 7hlf5/c5dCb89qvuqu2TERQK7kfv8/R2dnZ2dvYJioh5TkjkRM6tUxEHnZ2dnV08vf2vZr3i fL50XJCZlHhk0yaDX/7HIOhKSl7jowoxQY+PDvJ1d3LaZLHY4Je+BkFszcb3yE6NPXU68HR0 OiGRf/KyAQAAAD61job7tWVy8cMQr02rN9pu2ebu7u6+0919qf5Ca3v/+If0TuXw9BAPS9MZ 05ZvdtfhaG1jrv/PoS4xb0TyznTaZWpLZeIHx0MCfL3a5H/U6+JrMVHVrTV2ORVJsjNuRp1U H+O+fVGPJdwisojz8tHZxuMOuPAwmfH53napKZGIko4c3TBl9JKdm09maDcU5766GxXg7u7m 5rpiQu8lOyN0N7ZFqRA+vODheeGRmFP0aWsGAAAA+MKow33/rdJHiVUiDpHkxvJcwHCeyAix EDy7/a5YUZ3qJTg8pzOf3E+5VpyyPz/AROdxfXHaufL8zJJ7W7r7k/vcR7ToXQum/0z5/yg/ j5k4Q0/X+EEDp67Qd4vvrto+GbaAHe1rOmnsv74dOGjUPBuXA0lEgZR4Er7bddmI0UO+/evg mWaHkp+8LfisRb1Jeh1k8s3S4Ctt5fdvkqKCTPouDW433AcAAAD4onQw3K8o4j66aDZugfWh E4+YMpIkyTKSTAlfP8fQeI9T5KtyklR19K8E4a3oE1Eh558KdR6rEaQ8PW3Td+z+W7ni7v3k frWSz47atElv6HcDhnw3fIqBrlkTpk4Y99USWuaXlhOrSPLlraM2ZsOHfPv3gWMMjXZe4maJ ycLM2zEOMw1G9/7ffsOn24ZFP/u8b7s01JMJ9lb2Ppvbyu8b6usS7EfZ+7Qb7gMAAABAJ6nD /Wu+stdpJY8iGM5zdD99L+Vya3gxwtC1XXOTfbedRa/TqrkpxLUecc/9t/ffHF3Wy/hYzIPc Zo8nuO9y3LlQJ9yXi4UCDp1OZ9DpPIFEJldIpQX5LDqdQafTOQKRWPtZcamIx2PT6XQmk8Uv UCgV8sICPodFp9MZTDqvQCJT6I4jL+TzOUy6BiufXyBt/rlzuUwi4OoMpJRLJQIWk0Gn0+ns fJGow/eXLyCIKJe5Vo4uZ27pPpwadt7Luq/leWa+uOkhhVJRwGcytPUxGHSWoEAqb3YMUpGQ x6Yz2EyuUKosFHDZ7Ma2TJZAKpUrWwyvkBaIeNoumVy+4MXtzof7SrlCIuAwGQx1b20sqFtE ELJCPofDpDM5PH6hQirkcFiNzZksfoFSqWjZqVQs5HE0JXKEooICiYjHojPodFZ+gVTaagcA AACALtfBcD+f/yrSimoVkcPj6j7MOull57rF9VpeJ8L9NtRLnkaf3Tr9/5lde8kluqC/3+62 w4Yd3htC0ps9yLn74sT6P+mE+w11tVWERC6VSCSKopLKd6p6sraMkMukEolEXqQofafZte5d ZXmRRCKRSCRFJZXvahpqaqtK5OoHFCUllTW64zTUVGk2SiQSiVQhJyprm011g0pVVaqQy5sG UqlUdRUEoZBKJBKpXEFUkXUNHT3m9MTQfVbjd9JIUnsOlKyG6CWj1oScvstuekhFku8qS4oU Eh0yori8utmCtXXvatQHLC8pq66orCwp0rYtK6+ubzG2qr62tkwul2kaKRSl1XXx2zsZ7qtU ZF1FGaHQ9FfUxoK69TVVZSWyxq2VFWVlRdrmJZXvalt22rg2r1TdRF6kLK1UNZ5umaK4vBIL 9gIAAMCXRR3ue8xk7pvP2juH4TxJm8UfXcDNef2Oe75rwn23iYzzESUFeVXJN2QePTrczzju u89njU64/+y8l/N8CoXSn0IxdbnxOJ2RcPvImnEUSl8KhaLv4kNL17S842u6ahKFQhk+dJRt CJPPyI48ardwJIVC6T+UYhpy4zFDd5zsSDu7hcMoGqPWbj+emNOslGcpV3abUCjfNg3Ef5EQ 5zhuyPd9KBTKZEsf/7sdPeaPD/fzOG+P2fw06GdNeX0HUcY7Bd/NYurumOjjaTGRMnDicKN9 CbwzziYzJja2HT7eKeFulrDF8IxbQYdXj9R0OczQ3sEvovPhPj+Dcd1Bb/D3AygUCoUyoo0F dWUE8SzCVl9/KGXE3FU2kfR7Xnr64xqb//jL1lCukNGy08Qoj5XzNCUucDtw7Ej84dXjKP36 UMavO37/DrPlDgAAAABdroPhfl1dTUVRYVFFTV2z6LI2/ribv0eXhfsFmVc9d80dOz+8kinv cCb9SbQZ7svSX9/w/GEJ7W1TuE/k58RaUX8dSqVS5y3fFfWwUky+9ls3bdRQKpU6Ybm+10PN rrzkqKBlVCqVSqUuczyfkqXMol/dMZVK/Z5Kpc5z3BWVpTuOMuvG1R3jqRrD9GasP/OaJHVu BkQ0NFzdq/fr+KaBVKoGVuQ6q7lDqVTqsIn61rEkv7ijx/zx4f6DM47L5lJ1jFq1MeAOW7cz 7oOsQGNqnz7UXx0Oxp85f9beWNv2YMCdghZjVxbmZftOnTrye3WbAWNmzvDLYZ2x6Wy430Cy IvzWzhlJpVKp1L79vjVpY0FdUWas7/bx1L79vjUJzo054ee7srE5lWriFJOa3bJTLudlwFoq dYi6xInmhi60umzfNZNHDKWO0t8UGMVuuQMAAADA75p2Qd0WP/q80D1K1ouiSGee19zfHu4z 904UPIuvkuQSt05ynXteuJ/z4t65fSv9Y3kijuhNVmbW4xccTUPB2+dPE06Hn/AwG7LE3tFi nc2q5Su3udJoUTSa64Z1XgHhN+mNLdkZd+/fOH7IxdFkiNGeQ2vMTVessffwodHOnD5tv2zJ wZiHj7kEQRASATvJz3y1lY29RyBNw3vrdssta93OJhFEU0At4NHTkqLCY/yWz7KwX7F8nYvl 8nlrXMMjo2g0191OXo6uN3MIoiMfJf/4cF8sLcxKuXLpiqa8M+E0l9Xmpg7OEYlpmh3ZGen3 j+1zXzVh2LQl8/TWOh7aH0Kj0Y6Fndgwf8R024P3EnVWLngSvnvn5jWr7H01XQa4bdu0cOTM X4b8Wf9IZ8J9mUDMeJJw+eJFGm3/lkVrTVovqKskCP7rRwnR7habDUePWbB+kulOvyMnaTTa aX9Pl6VTx689cvZpLq+xt8aFfK1tnF2ONFW422rDqllTZ84e/ZOF+6mLCdlcNhbsBQAAgE+v cwvqtiBKOHAq4vLZR+KyLgn35cnx/tsW/Wp5SERKatpv/jlow/0ykkyJsA+6eCeL+Y4olTIf PBeVVTRWWVNRLHoed+92yJ7lNpuNV7oGbjSavsrp1NmIuLhQ/wNudjvOcUjlO5IkyXJZPvPJ 5bi4wI0TVznaWW7fY21mutUzLi4mLu7QLqf9B0ISRI0jMxOOH9ppZbr1QJxGeGDYzg0zFu+P 4UjEja1qVCrR25R7d8Oddzpt/tXUNcpmkfEaJ5+giLi40IgIt6WLzqdwlKUdO+aPD/elvOwn yXE6jrl7bdm6wjEyhSTL1a3KpQQj8cYNh0UzFxhO17ey2eUaEhcXdyMuzmObhbHlhsDITO3A hS8TaG7mMy09T0fFqPu7cCbMfdW05ZP7fzt3eyc/uV/Gy3uefCcu7vyJgw6T/rQ8qPWCupWE KPfphaAAk35zFq2cvHzXNs/guLi4G9evH9+w0NTK2flCukjTVpaWEuW52cJ625E42pW4uLi4 c8f99tosNDKfOWLI0o27Q66+YOSXd2y6AQAAAHq4tsN9g/xQN8Wj+5WvDwn3LWZ1wT15prC8 LZS8jHf8RPnl9YweE+4HGPQabWSy1s7Z2XqNidEvfVYdofNy226dz6fHuv86bqGRkdkW98Nh t9IJQk4Q2fG0pKR7qVzdlnnpN4Jsfxo+Y4X5+m3+4TfTcghCViB8du7orbScbCFBCN5yEo+v Xr5ss8/Zm2k6nwPPjr+x38Fmw441F57zdZeFlfKJx26WxgtnzTbbsCNgX3S6SCwniOzHSUnX YlIZnQn35xtOX2Khu4DwukXLjBY2D/dbkQmIZwG2c4zW7g65wNPdkHrv0nZ96vcT9dwDrr/K FhIEwS9g3Ti34pdlTtEh94QEQRAKMcG47edgs2Wn/+kEbd7PeHz9nKup8eQB/29Bp8J93SJO 7ti7vnW43yj3mo/fitF9f1lhfjQpLU9IEISYmZYasW3uyLWHEtKyCIIgCCmf+SzQ3G7zLs/w B4+bTign5Xyoy7J506cOneYVxysQtFMFAAAAQNf4jeF+4/q6uz3D4tJzO/zZ8LaVPA895mA1 cWnwK5Ks7Jouf7PbDhtWGo813ODl5ezltWwSdYljWFL6e1vnxbpvsZo5a+EWB3f3CymFRUqS VLJev4yPuVdIlmpv71JBkpnBS/VNDQ3NtnsGht55RZJVJCl6/iA9+cFzOUmqVCQ76aTPzvUO vqF3WNrulayCxOPuS5dahCbd5za/3T//WsxBq7HjFm7Y4OEclvKSU0SSSqX05YVj95iy0g5O ZnpiqMOSvlNMvLycNQsI7962d9mPlCUBOuF+W0RJsftsjWasDxKTcu3xKhsaztvPGDVn0lr7 wIfP5SRJqkiSmR6y2cV21/oYRWOrEnrKxSDbdXaeMdqViiuVouxo1z2Lhw7R3/ob77mvYDw7 v/RPa0Jah/skSZIVguwM56Hjx+vPczoTnVFAkqSqoV7+LMhtjd32vdGaMy66GxzubrvJ69J9 MVlWS5IkWSHMeX7exXrxsIEjbfdffSlso28AAACA37c2wn193jF3xeObFcwE5TU9lkeX3G1/ Njs4uKKIXZUeKgmZ2HPC/UPzew0cPWbiDD29GVPGTR/5w6pAxgfC/avuvw6Ztc73SEJO200a 5aXfOLRlxNBxjtG3X3Jab5blJD73N/xx48Xraa225sRcDrQfbnwyi1co0zyoDvfnz1qy4ciZ tJZ7dJA63J86ZdCo8bprCE8aMfrXGS3CfYW0kP7o2q1rMU3Ox8T428yaYbXt8MlM3T5T713Y ufi7SVuiOc81b3IUsIioFavcIw/H0QmCUBZyBLGbzLcGHY5uecZFGXG3dk/9v0VHP3W4f2C9 /giLqId8SdN6wTze2xuuY00CE1LSCIIgxPy8lINzpnqeu3On2VsXBCcpKNDGcMA0rxsI9wEA AOBz+S3hfk1xITf1YtA2oxWeF29nFnbRXw3lr6N2OK1fNXf/yy7qsCvcdtiwZNp3w6cYGOgb GEz9mWK4I/LD4f6aVYYWK8M/fAjqcH/KIks3nwRm680qVUP5VZutroFOF1ptLeM3PNw8d9WR 0wl5VbqP86/FeK+aNGmlTwopLvvYg3uP9MRQ2wV/HzjGwEBPs4aw3kyDMZT/XXiwRbhP5Ofk PIrXEXF45/rVM01cM0mx9i0FZUPDeftJUzfuuRSre0Dpx2nB3iYn6OrfKl9Fhh/ZZ+LxqOVs NNQJI1aYrN/zycP9PcMmmhwKustuWi9YRZK5V/d4Htp78k7jr7JEn13+rn5Romb7VktyGUEz x0zevg/hPgAAAHyJmoX7kxh7ZrO8XYpykqvYt4tiuyLWV//4z+feffyuklV25qDQuQeF+9rb 8jBe3D7vtXBLJIdPJ+TSggIRXyQmCJ3FWfP59Jvuv5oGxj980k6/eek3Tu+avOoEu+33CfKf xd7cNdn0BPthG5sf34sNMJvsmcAR8TWPqcN9u8CDEe2N3L6PvS2PQiZhZ6YEm/WfMPhfvRr9 u1evb/7239/NWN8q3I8NMJ+yt1nNzcN9aX7eY7fxix2C1b828yap8/fc1y2ivXA/zGP9mmjd rS3C/TfMnCCzb5Z6X0lp+QZK7rVrAQ4TpnndRLgPAAAAn0unw/2ayhJe8tlTOxZS117N4XXd srd1OVdcTDat3OL8oMu67ALa2/JUkuSrSKtdEXHJmWRDfW11mZyorGu+AgGZF+vudcgjNLGd TtXhvk3wxaTnbW1WNTTkBS/1Cr4Y2sZmZUNDtMPSfeGXXwh0H+Zfizl1yNixvZE/ykfdlkel Ur0rVdwLsF436ZveWv/+5u99B45sHe5H2y9uVXPzcJ9/zfWAi63mV62GejLBvpP33NfRbrj/ wuWnjREMna0twv0Gkkw4ZmXvuFn9a7Od6zJcjOa6BCDcBwAAgC9Rs3B/DtsnvKyAU806I7/Y RZ/Zd57IcJ7ICVkoZXPqFc8LTzkze2a4r5BLCgXs/EKlUkHkJBwN9N9+4DJB6Nyk5o8V7uel XDm6YnA/w72RsSm5jXJyc6/7Llto54BwHwAAAODT6nS4nxW1y2GVwTSHyyJlZU1d1y17yz7t bbZm5fqg69Vd1mUX0Ib7DSRZU1FUXFFVXUMWien3/KZaXWDyec1a/5HC/YaGB55zFy1fv+lw QqHW8/jjbvZ6CPcBAAAAvhzacH8pLzi0+C29Kj1EGrWc69N1H9t31s8Pdy9TKmsYh4XBBoye Ge7renndz8fDyu38pwn3ZdmJz/0Nftx08Xoat+W2nJjLR95zW57PGu5np948vmmmpdeN9By+ Zg6kBPH4+KrFDo4dDveVhRz+tY3vuy1PgvPnuC1Pe+F+IT8v+eDstm/Lc8TGCLflAQAAgM+p c+F+ZuQOt907dx69nvJWqlJ1wRq6GqJLm9ausrPyS5J2Yae/nTbc16UQvYl3Gbok/C2n+R3o uyjcVzWUXbXZ5ha4q83b8iRvmWcReDohr9md9D93uF/a0JDsu2Lz3iNX7ufrfnuD/4x2wGVh Z8L9xtvyeL7ntjwbPvltedoL91UkKU30fs9teY7OGjN5uzfCfQAAAPgSNYb7y/lhR5WpLytz wqWnTDh7JzKcJzI8ZzBDXCXX9nD9l7fM630XcSN9ZXdDFXfDZJds+Ic/GO77Wghv3nxXKqu8 uo3f7D0DnXBfRhDpCaePHHJ29vAPOZ7ILJB2ZJnYzummcJ/gv+XcPmax3HR/VPJTnfV0CW7q vaPuuzbar45O54tbLaj7WcP91HuXvEx+tDyWxs9Tp+FilvBFTPDeTUtGjV9u2+Fwn1CICcat /Q6bnTyPX36izc6FWXfjDq43nTLwMyyo2164T0j5zKeHzbZu2X/w8jPtmr/Z8dG+lvOxoC4A AAB8Xh0N96sI8ZtL+9wctuw9GXdfu4SugpH8KO1hBpskmyf9tSQpzrgcEubv5XU06lQS+4Pv BNSSpPj2zukrN/u4x4re36yA8/JmlJeXl5dXUNyrtwWfZc3d7gj3SZWKZCWe8N650zes2S3u Kwtk6THHTZZanrhzj9NqQd3PGu4rGxqi7Wes9T5+73lJU82K5w8v+tubGC2c3JlwnyzOTY4J 2r7J4cRDsaKscTXemlJpwb1jnqY/D13wyRfUbS/cJ0mSFN45Fu6xc6v/vTckWd00M9zbhzcu GTZwpK0vwn0AAAD4En1lyPadyDnipXxJryWkVal7C887is46is46iq64i5+/qZU8Ep3e1TKv D94gfPq2nqxVkWQt+7T03IfCfdapzeIsZq0iV+67kev8nnC/kCDOueqNGPzVV38ZOHmix2O2 UPahP3d+MzE7O+vqoZCNk/8+aZOTb0hMM0Gua2w2rmwK9wveZj++ExsTERHqbj5k6nqP/QfV rS5eiYl7ms0RNcbFShkhePk4Me5qzInDbluXDZu1+VT4CXXLy3HX7mSypHLNIUkErDv7F+xw 9vM8ojPskT27NuywcTmTRBBSTZEPY2POR8T4m802XG+17aCmbWxydg67rRj7Q8fME+fcunbF 0XT03KXLt/smPHhMJ2QKgvPi3oNgO8eVev+c7XQy4vYzJl9AZGckBOyeNX+1Z+TRyJiYmJiY iOBwD6vFhlOH9x04aeE6h8jGfQnOi+cPgr1drKf/aOF5+tLtHC5HQoh59OxbYVccp88y375u 38WktLcCglASxOPTTq72mza4BmmO4oSv0w6TCdNHfv/ncRuc/S48fJHHJcTSwuxHVy+r1/E9 vm/Hhin/nLTplJ96KmMTrj+mS+VKgiAIgs+jP70XE3MpJiYmJuaA7eKVeuNnO8ZEnouJiYmJ uZn8IJNLEEqCELxJTbzgscpuhd6cXdciE1+x+GJCzGJlxtNC3MwGTVnv6Xci+WUmlyBkIiI7 wm+djZ3D3v2aEn3stlrr/zLHELflAQAAgM+pY+F+hVyUet5p0n+MWOzgFEDTWUA11HXFlp07 j99uGe5XkmRmiPGPY/7+1Vf9Z41xuN3Q8P5wv76ELLnlpTdho1tUNOMDRTxPCrOe+dVXX331 VX+r8xczFB2ov+PqqkpL6A+T/YznL1k1f3NAfDO0s8e9TfsuCXnNYZMkWVNcKsp5GB+fEB/q amaxbsWWvZqGd5+/ZEjKNZ1WSQro6ffjr8bHB9lMWrBp1z5tv/dz6IXFumvkMm4dDN1nt+2g 7rAnIvc5GBn5XGKLxU1FFtMfJt9NiI9wcbJbN3mpduQ7qS9f5JeTHaJSkbLcnKcnvLZYzB1s vDM+/i67RF5BVsj4zDthcY4TB8yx2ep96dlrvowsVTU8PG1ltm37/n2R6gFvxp9w2blx8ZQx o0YOnbI8KD7hbYm8giTLZcXMOzdvOi6eYLF1d8i1l8z8clKlapC9ffT0hM3OTaum2J65lcwo KKuuIcmCl7diPFcu2hZ09sJVdadXoiOO2BmYTx3Qb/yShbYnHzzOKyBVNaSMl/NUvY7vzbgb nosHLF69zTZQvcet+KdsoUJ9bdeoGkRvH92/r568k4cdJ/3nHJujPqfVE/Tw1ouCksoakqwk CvKexRwLXP6t/raTPpdeveYXk3VVDcV5GQ/DPUxXrFtp6/fw8YsCsrKWJGVpKad87JZv3xsf f7lxCeHAsF3Lp5rN/GnUdtyWBwAAAL5IXxmyfSdKUo5VyJR1Za1+SpR1wgfCUPuWkX3QWsHD p+/KpHVlyurXx8SRHwr38y/YKhms6txY9r4VjPeF+2KCuLR/+YyJvXp9P95ggf8zjkj+oT93 fjPGraOBlsN7vdfEmeZ+jffcz4k8arugjabUAb3GOh5Nymz88L1MQDw7YKs/bkjrlt//+uNC /3iOSCcalhHEs0hb/QXNWuut9qYlNS8yYHXbRY5YczT4tu7H/j9CXnLeMeNhA/upe/h51grb y4RAQiT6mKyYoH7su169TPZcf/ycIAh+BuP6Dr3B/fs3DvjzkFEbQ9h3/bbo6Q/R7kskens0 7tynV69xa4/dTWQSuQ8vHjXu1TjOUAOjHVHpBKE+nU+jPJzm6hzGJEuLHQffHjUeOqBvr17z LX0v3CVyOW+Pbhg64Mc2D3v4nFG2l7lC9XsfTx9edDLu1atvmy0nrbHwv0sQMoJ4GrFFb/5g 9fEN7WVyIu4Jg6DHxx9a9UuvXpTGtn7+d5tmKTsi0Ga+dtJHWtl77A7CPfcBAADg8+pYuJ// 6FWQMZVK6d2G2cYOkQ9ahvtVJPk60nra3CG9e49bNs/zwYfC/SoJ+Wq/9TQbz6iHmR8qIiv5 3A7j3r179+49zv5KXJayA/V3XKWY/mr/lKkjvmvrkHv37j2kd++1Qa/4PJIklVn0K/ZTevdu o+mIldYHE1maTkW3r+9fMa51Mwql9zh7v7isgmYliLKu77dv1nr8r3p7Y0myWKfIHN/JbRY5 ZK61dSSL7BBVA/nA08G4cUgKlWp89M2jfDCNsWYAACAASURBVJL7MCpgqabjuSZOZx+S6q8X RPitnTO86Rh69zZ2jKZFXPPZPla7L8l9kKXdecS89YfPsMmG+rr7HnMax+k/qs/0A7Esqfqb CEXcrCtreo8d3LTH0Al9ra6+idxmv3Rs797jJ+h7xZINxeT9CPuls9s8LdQ+vY2PXkjNV3dW X3fFY87YsW22HDqx77rYN4JikhRlXvPZpmk0d+fuc9lkZUFdlo/lpJ8HN7ZduC6WFKq/o6DM fHtp22TN6R6iN9PCOzvDZR7uuQ8AAABfqK8M2b4TmXtns30M2b5t/XjrMV2nt4zsXaYyPeez fQ3YvobsfbOZbh+8LY/7NNa+hex98xh7prw33C8iCLGQy2Lm5uYx2WyhTKks+qR/LykkIhGX kfteTBZXKCaIIoIg5IWifHYbTfPouUy+SCpvvH9QkZKQCfPZTHobLZl0tlCiVCq14xcRhKww n81u1prNFRZKP65IBk8kknTwzkUKqULEodPzGntgcfPFhLKIkAg5XGZjobm5HL5EJiMIQilX iPlsel5e04B0Bq9AIRXms9l07b6ERCho3DkvN5fJE0klCkIhFYs4uY3j0NkcfqFMPZMEISsU 8Nm608zl8oVNVakPX6FUiHh0ehvTmJuby2Ax8sVN14ZMKuZzcnPz2mzJ5HGFUvU8F2jmOY+e yymQyBSEQiIRcZlN+zJ5QqFm3uUFzU43g5f/IuYywn0AAAD4vDoW7te9qylTFLZNpiiuqG4Z 7qtIsqaiSCYXFxZKFfKS6g/dlkdVT9aUFsmIkorqmg8VUVNdUawuQkpUVtXUd6D+jmuor60p lckk7znoQnFhYVFZTV0dSZL1NbWVhKzNVhJlUWlVrabTuqqqUqW0zZbS4tKqmrpmJdTVVJUS zVpLpfKSSpJs+IgixfKioopaskNUKrK6pFihHVJRVvuujqyrrtA5+XL16SZVKrK2orRId3BF cUVFRWVjzep9ybpqnStHIi8qq6glVSpVdYmsaRxJoay0qrZefVANdTWVRYVSseYwpIVFlbUV RLFCqj78KlLVQFZXFCvanvDCwkJFWeU79UQ2qFSVJTJp2xMulhYWVdXWNZBkXU2lzjzLi4sr asiGelVNaZFUIm5sKy+qIhtXj25xusVymZBeleFiiHAfAAAAvlDaBXU//083L6gL8BGyr3j7 bjKaYnfjlVD6ab9OAgAAANCkcwvqAkALpYLsh05DZ68/dS5VWNV+cwAAAIDfGYT7ALpyntwI P+qsZbtli52zz/HbzEKZsv29AQAAALoCwn2ATlEqRSkXvbwOeDVydXXdtHGj/5Ws3MLPssgz AAAAwOeFcB9A1+ObJ1y26Gktsz8ccJPe3VUBAADAHwvCfYBOKSigX/A2MDA1aLTU0nbzOY6I eNfdhQEAAAB8Egj3AQAAAAB6FoT7AAAAAADQLoT7AAAAAAA9C8J9AAAAAABoF8J9AAAAAICe BeE+AAAAAAC066vwwqSjwpvd8vNazunuv5sAAAAAAHochPsAAAAAANCur4qLi7v7jxcAAAAA ANBCuA8AAAAAAO1CuA8AAAAA0LMg3AcAAAAAgHYh3AcAAAAA6FkQ7gMAAAAAQLsQ7gMAAAAA 9CwI9wEAAAAAoF0I9wEAAAAAehaE+wAAAAAA0C6E+wAAAAAAPQvCfQAAAAAAaBfCfQAAAACA ngXhPgAAAAAAtAvhPgAAAABAz4JwHwAAAAAA2oVwHwAAAACgZ0G4DwAAAAAA7UK4DwAAAADQ syDcBwAAAACAdiHcBwAAAADoWRDuAwAAAABAuxDuAwAAAAD0LAj3AQAAAACgXQj3AQAAAAB6 FoT7AAAAAADQLoT7AAAAAAA9C8J9AAAAAABoF8J9AAAAAICeBeE+AAAAAAC0C+E+AAAAAEDP gnAfAAAAAADahXAfAAAAAKBnQbgPAAAAAADtQrgPAAAAANCzINwHAAAAAIB2IdwHAAAAAOhZ EO4DAAAAAEC7EO4DAAAAAPQsCPcBAAAAAKBdCPcBAAAAAHoWhPsAAAAAANAuhPsAAAAAAD0L wn0AAAAAAGgXwn0AAAAAgJ4F4T4AAAAAALQL4T4AAAAAQM+CcB8AAAAAANqFcB8AAAAAoGdB uA8AAAAAAO1CuA8AAAAA0LMg3AcAAAAAgHYh3AcAAAAA6FkQ7gMAAAAAQLsQ7gMAAAAA9CwI 9wEAAAAAoF0I9wEAAAAAehaE+wAAAAAA0C6E+wAAAAAAPQvCfQAAAAAAaBfCfQAAAACAngXh PgAAAAAAtAvhPgD8cSkkIlE+l8UtkCqLlN1dDMAfj6RQwOVx8gUSoqiou2vpeWSFAj6PyxZI ijA7f0gI9wEA2tVQX1tTJpcrS8ura+u7uxiAP5662ndlhFRKVNTV4BnYSn3tu0pCKiMqqjE7 8Ikh3AeAPy563OGDm5aMNg5MEkpE3V0MwB/PrVM7l1ks3OgYS8gU3V1Lz5Ma5rDNwnDqzutS Od58/CNCuA8A0K4K4auXvjMmLnANTHxT2N3FAPzxMHNT91v9MMwqjJch6u5aeh7p25TzVoNG WJ2Kf1HQ3bXAF+53GO5LhUSS3x4bM31dW4PDb7/q7sq6nuhN6sMjlssWL9TX19fXX7fZ7WwS QUjbasl9RDvvuUIzHZ4RiWldVUR2/N1jds1m23yzhf/d/II2C/ld4Lx+dC7AUn/RQv2tIcmJ r7u7nI8jepV8P8By6aKF+ttOnL3zOyn6s3t8aueetfr6+vr6hsv01xy7nE7nfbD92yteHmbT +8z0jheIBR8zAOtZXrST8WIDfQvvoGtPGV1SNHwaqSd3OK/RX7p+927aa4kM2WjPdO3oxtkG E802xBBShPutPDiyfq3BpGGbLnZjuJ8SYudkqW+80dUl5o1c0a1fIHhxJfagjb6Rmb7ViRvZ bH53lvKZfOHhPjPhzrHtRrqsXXdEZnZ3WV1PpWoQ3drvu83cyMjIyMh80eL9lzkScVstqxX5 7CibzZbGRkZGRkbrNzhGppBkWZcUUVrYkOyzzdpcO9uLFhm5XE7KbrOQ34XqhnpWvPembeZG 691Dz2R1dzkfR1VfJ4z39t5qZrTBw+ns76Toz64g4ybNuelCtfQ+eCnjw5FYef7Lp7t/HDDO zut6lvBjBmioIzPCAnevM1rhsP3wHS5J1nRJ3fAJiNJvnN9ttGipyfqQZxm8rnk5hK6Wm3Nv z5K//H1JAPsJv7tr6XnE2UlhS/767yVHrqQJuqsGQdrlqF1Gi03MN4RmZPLLu6sMkiTJIk5p 4t51FiZGa/2O3sj6/f4XpGfq7nBfmJ1998wBZ2cX51Z8z8bcz+a23EFQyL1NWz1v+Yp1yzc7 aR25ejON2R0H8GmJWZkvLvq6u+xycjIznGSwYKH7eYIQt9VSkJmUGO7l5GTv5LR46gADK5cz t7qmhJwnp908li2csdZpu2PTbHsFeEeni8TyrhmhGwiYmYnnXDcuG/4/BnuunO2yt0E+LTHz ZUa0u6v1tOFLPPdHPe3ucnqorLiQsP1OTlvXbjKd2XvotqA7mR/O3wUvbydEHd8XkpgjkUs+ ZoD819yEALf103/+xXp70K3sjtQmZr54fumAh+seZ2dn58NRUUmN79BwUqKjj3k5Ozs7e3g7 n07JZooIQeaL2xEHnJ336LwgevtfSpHItF8vkAqJp+dCD+9zdnZ29j3mfylDIlMQBCF4mXg7 wke7X8A5zUAEQRD01LTLR7Vb94WGRd948eJGYOCNx7m8jn13gZ765HJQ61duZ2fn/eeSU153 9osQnJTbifeuJb3p5O46sq4Hh27XN19hMcf3aQGS4x4q8+GlE6ePRl3MIBR4/6WV3IcXL5w+ 5n8pQ6HstlT95bUjB6ymzF9kon/gmezTniR2RnzCnRv3XxJE20eb+yCZ5rZxg/GQwTsiHr1m fcpSeojfTbhfW0aKH1wOCfD3asU/LORShpgka1vuw35xcrf7SlP9ze5aAZGhd1jdcQCflkql kqdfuBDi6+5ua7d+ybD/WHo4k8Nuq2VNiaTg7tGj/l7u7utWLlwya/xOGkkWdUEJRUrWzYvL pi6x2mHtqJluD/fIRy85XdF996hpaBA9owXtWTx6icXmXXe6u5yPo2qolz+jRfuuWrLKRn93 UneX00MpGM8ehLu7u7m62+hNnmZt7R3P+GD7muJC4d1jgSdvJeeJSz5mgIZ6knHr2mHrRQvM pq8IyyLJqo+uTVVfK0+/QAs94OXl5XXw+P6rb+Ul1SRJVghzsq4HNb7unUq4kyUma4prhfcu HDt0QPuC6O3ldS7hFb9ZniV8ln491MvLy8vbx+tc2it+ceMR3Qs+etCncb9DIfuvvlWUvmvc pUJemx0TEujXuHV/kG/ogzzmg5s3HyQ9YSk/+ljUXdVk6XSl42B4bGxmxzrT6VZQQE8Nu/qW 0NTcWXJ62v2gTXuWjRrreCs+5/f7evVlk0k49y7s872QphQUd3ctPU+ZmP3igveBC0/fCj7q 9elTkL19FO+/du3MASMdEu68IT7lUOVKQW5y+PWc0oq2j7ZMXJFx5rCfxezZdrsCktr8vxB0 WneH+9zU1GiP1Xp6C/T09KYOHzZgAKXfiMl6evP09PTMPf0vpNJbtJflcDJ8F3832zH4zr1W wf8X7eZppx3W7w/3mxQQRJTLXCvHrgr3RZeCHayXz3c8nkMUflnhmIiZc9bsGyvv3024TxAE IeURqS4WW44cQbj/Ybwnry45jB7hENJeuN8ZEg7xaI+5gcPuDob7wpwHdw+YLhrb55t+Q4cY Ou0990z9eO41H3ezMcMG9PnnyAVzdl1NzeERnOQHka6r9PT09fTGDfymTz/qN9TRo4Yucn8u eq15C6KQS9z22rFu1vDv//W/3wzrZ+j3ME9SICfYD89GuprNnjF1FOVP/YaOG23upRmInZF0 /4Sr18alja+xenp6euarVlnu2m3a/0f7kHvZHZurzOvxh9fOmPoT5U+9h46bPEVPh+Uur/DE Z3kFHeqvUcZRd48Dtj6Jndm3teTgC4ccEe4D/BavL+zxdljz6cP957Tdrl47/C8RxPuHycxO P2Y01IGGcL9Heack2VG+NquXGxgYzJsyY+ygv/510C/T58wzMDBYvnWTTzybJKtb7FJ+LXDj OmvLQzEf9TnbLwaL/SJ4yX8sPf6ecF9HemLoPquuCvff5dKTfef+bZb3Lfbb0t/eXc/y7JiV l+PvJtxvlH/l/MnDZgj3P6yhlsw9ssvaZVt74X4n5V8+6+Ni1MFwv6GuRnBjr+eKcT8NHviP McbGB1IF8gqSJIvz7t/2WTp50N/+OWjcOKugU0lsskpWkxe513qFqYHBzHE/De3z169/GPP9 3ydsPJH4UDcAzbtx4/CaGZMG9/rP//rTqC0HY19Jq8gqKSsvcuO6FYsn/9R38MABg+ZtMj6Q KlRUkiRZLuUy7kTGulssXrZIz0Bt2aLFdr6+K+YZ2m3xS2B2aBKKBVV3925aPe2nvt8PHDBy goGW4cotNn4xj5glFe86fqNw6ePn13zGmF/iiroizZS+qThnOn/vXYT7AJ1Wynqc4jJ2isud TxzuS5ipl9wnrD5TIHv//++qSfL6ATu/Qwj3u1p3h/u6Xp7w3+GwzCr0MUHIWm+VioQ8Nj0j IS1y05gRm7yjbqfS6XQ6nc5g0nkFkk7crFcpV0gEHCaDQW/S6a4UMkUBl8lk0Ol0OpPL5RfK NZ87U0ilonwWnc6g0+l0Tr5ILCUIokhJyEV8DotJ18ERfPCz8J833FcfEYNBT9q/Z/0mwxUH b9Lpb9V1svN5ohY35FEoFQV8JoOpnUgWr0DZYiLlhXw+h0mnMxhMrkCqlCulYiGPQ6fTGQw6 S1AglUvEQgGHzmAwWYICPpfNYdIZbC5XJFXKhOq5YrC5XJFcqV1XUKFUFOTrjKvpqtUpVMgl IgGL3nSumWyugJmbc+ZzhPtKpUIi4jBZjKa5YbIFBQIuTyhsFTcq5RKJgKW9IpkcZn6BVMgW FEobLw1NuB/xUCzgNLVjcQWF4pbHrB6XwdK5vul0nlAiU/dUpFTIRBwOi0Fn53N4ggIuncGg 0zlCkVgsFQu46iuWI2x2TUqFQh5L95plcgWCVgN/FHmhiM/Ruf45+SKxRC6R8HUOn8Vh8SXq 0y0rFGgPt+kMiuTvX4GzvXBfqZCL85lsdQUM9ocW1FVI5erngqYqVq4ypTPhPkEQhIhJXFi3 cL2XR2Syduqkwhe0vT6O65YEPBdJdOazSEnIRDHbZqy0ttC3st0x6Qe9w8zUvBYTfv247YJf /+ubPoNnrYthpPMaszdBbkbksr+t8b0R/azxgAlxfrTDXIOZBkudop8TRGMvTyLO20//57/6 /NcPdkEdDfcJgiBycjMCl/1t8f6bac90Hr3lqbfG2tb2ZEbTK6FcIsrnNXu9Y3PyCyS6n89V yhRiPpvBYCR6Ozi4rt19ocXpLmjrdEuFXN1LkpVfKOALCoQ6jZODLxxynO39mM9lchqfDCwm W1DY8fWTZYUCPofOYDJZgkI+R/0CxeOJpEUyYX7jCxSPVyDXLnyqOSLtU5BJ5xW2eX8VhbRQ xKXrXPscnqiAx8gvkMpb/KugLkM7j/n5PL4ony0oLNIckVIpFwvZrZ77rbpSDywXcXWu7nx+ oVwmZLNZDDqTyxOKNf+WtRiXTmeyecI2T8pHUcrkOpPD+vCCus2LpLM4LJ6okMfgF0glHf7+ mEIhF+UzGEz13BXIipRNx9u6jBbj0ukMJosllMnaujWNUiYW83WmnMVl5RfIhGxBoUy3SHlh fj6n+TOBX1DQ8n88zc8gq/WCukUEISvMZ+v2xBVKJVKJuNlrNJvL1zzL2ngO6mxtRiLkcFm6 Pctenvuk4b5SIRcL2XQW43aI3XanjW5hdHqeZs5bPK004f7D59k6U8kVylpfDOqT0uyqZbF5 hUXap6BSQYh5HBaTzuTyhCKJTMRj0JlN13fzcbvH7ybc16XIeHvVZehQlytvRIrWW+ve1ZYX SSQSSarfjjXb1uyITJU0UZSUVHbq3hh1FWWEQibR0emu3pWWFMklEolEIpPIy6rq6hvUj6vq VbVlhFwmlUgkErlcUVpFkg0kSdZXV5U17tBIXqT40CdVP2+4r1I1HtHb2w9ObRs0aHtEak6u uk6pXEJU1dY16LYmyXeVJUWKZhNZWdn8OxcNNVVVJerJlhNl1dX1dXU15YREIpVIJDKiuLy6 pq6mipDIpBIZUVJUXKJuKy+pqq6urCoratyzpKq6tkF33Irm46q7qmt5PA0qVW0FIVdIdQqs qks9+hnCfRVJ1lWXEUXa60xOlBQXl5YRxZW1JKnSbapS1VUQhE6VkqLy8tLiyoryMs2loQ73 nRJUVYRCfVlJpDJFcVktWa/68LgSiURRVFqp6am+uqysSKY+oeWETCmTSORFyrIqlaqqVCGT SdS/6lyTddU15Urd7iQyhaKstq75wB+lvqa2sljn+pfLlWVVKlVNq8OveldHkmRD07XR7BKr rqtteE//HxHu11QUF2suHXnJexfUVanI6tJipc48FlVUMWM6Ee43yggL3b9n3p7rivKmqaur Jhipt3ZNWuKd2DI7q6t+ffXQXrNR470v7JzWf7XTmZPPWnyXif72kYfRV//d5+vBhh6Xr7C0 F39aoIWn03aXu9oDzrl2ePfC4f1nH7rFVzYOo2BUxqye+jPlL/2NV3c03CdJkqwlyfhAi21O OyLu6jzKunM8YP2Ucc7PmLLKBpIkyfq62spSuUTnBEol0uKKunrtnKtUZF1FaZFC9jrudoTz 8MVh6VksbeP3nO666ooynUtSqiwuKq2qKlaUv2tq3BTu30jnl2qfDEWlVTWtvhPWjvramsrG F6hSori4WCaRSKTykurq6srKxq6l8pJq7QuU5oh0L1tlaWlVGyOrVA3VpfLmV1kFoSwtK61q 8a9Cfe27Sp3ngkyhICqrCFlxufaIVCRZW1Va1Py5ryRaddVYZHWJzuUtLaqoqyovLS2SSaRy qaK8ur6hoa1xJRKpRKosqa5/73Pww1QqsraitEjeOLBUWvSBBXVVDS2KlBRVlBLKsrKysg5/ u0NFktUVxUqFRCKRKaTF1XX1DXVVpU0nsHkZLceVSCQSGVHe5ltWKlVDbUVRkVyqW2RFKVFR UaFbZH1NZWVx8w4VRcXVZH2zaWxxBqWSotYL6tbVVJbq9iQnysqr6xrelRbJpJqrQyotrqhX P8vq62paPAd1tzZTW12u+7SSE2WFbz9puK853ldpN8J2/GISlPXmpXZ8qbz03Tvtfzmawv1D 8bkV2n9E5ERZeauLQaVqqC3XPSkSiUSiLK1u9hSsKS8vlkukcqmy7F19VRmhlDddk83H/fL9 fsL9O37eqydRev2r1z/++uc///V/v/nXvykUCoVC6T+EYhoS2+oj/u0TvGTFOS4YNmAApUn/ oZ3siv4oL9hk+ODvKBQKZZih4faz6QTR+GcmIyEh0HIchdKXQqFQ9C19aHcJgpAJiGf+dgvG D6Po0HfxoaW/f4zPG+7npbw9tuynQd9S/vX3v/31r//9l7//k0Lpra5z8pqV/ndbtOa8PWbz 06Cfmw7l+2FjTE+wnzRPCrMjbG0XDKVQBg4abuSUwMsSJp7ztJhHoVD6DqKM3xV8N+vmOc9d 8yh9Bw0bvyt0i+GMBUMpAycuNtp/L/+ht63+uKEUysCJi40OpecXav6Cz+W8PbZx2EDNuJqu Wt2hiZ4Rf3jHOMr3fdTtfpy42GHfrZxQk88Q7vP59Fg/vcHjGq+zgYN+nLUrdI+BqYdX6J0W y0Twn9+M3TFuUP/GKikj541YE5LoNsP55P2LGQRB6IT7e5xjnOY1HfaoRY4nz7dccoLPp8fu nzdonPb6HkChLHeLT2vsKT/36f5588cNoEyxmmfhFGRMGdCPQlng7n/p3IMYJ2MKpR9F/WuG tsvb+9xWTNC9Zn9c5OgU3am1LrLCA2z0R2h7WmDlf+laetxV+3EDv9Mcvt647Vf5BTKCINLO uOyc22zkyUudAp4Tkve9s9BeuC9iZsesHzz1JwqFQqH8MPlDC+q+vZ99xHjw9/00Vf26+TT/ jlMnw32lgijk3T+8ausuz13RTXfLSfBydtpl5nWNI5IpdbMkKY946rN2orG1R3j4najIjb/8 w+T0zactPq56/bjtlrWj5jp7LPpmouvxB6/Um1uG+0IGccFa38rD7WQSh18o0yR6soLCV7fu htr89POO0K4L9yWC84FuXg725zIaP4GbFXdww8oRumdwmr71kWua10mCIPKfvrm8fdb3/b7/ 1/9+/fXf/vK3b3Qa/zTVxPlIBiFtlSsm7DUy/VXbbvT6k462u0L2OgdpGicHXzjkONXx0n2P 6XPGfK9+voyY5BAukrA7eKhPwnfbz6F8O2zEr3vCty6YNG8I5Yeppib+dwpTvNbPGj2EQvlh qqlJUEahpkpe2quL22Z81+97TX0DR1DMI+5mtDHy66Sow0sp3zZd+6MXLLA4HGrxreXRuxkv m7d8fNrJfo72kKdv2GBh779piuOZQmlTvzx2Tsy+Gd+N1g78A4Vi7tWqK/XAGYeWfN808OgF G+zCc5I9Z8wc3Z/y01Iz15imM0g8Pu20fbbuGfxpmplrUAbRybUMeGk5MVunf9u3v3rcDy+o +/pOxqEl3/XTzM7CURYHIy362R29dz2zowO/fvv84Nrv+g2lUCjTN208+lDMykrbN33GqP7q MnZe1ynjVeLzg4u141Io3/44foLrwydv2/hKCu/JpQt2v2jbjjEcbxWU7D7F8dQT3SIzQ62s 5g7RnccZNsHHHrbsjJV1wWtqv1H9G7tqtaCumCCehFrNmDNY24+h94MbCdcueZv/otO3oc2x G41nMPOa71rz4c1G1tnaTLyrnvE4nZ59kkP2f9Jwn8vMjN47pc/I/v/6v6+//ttf//YPnSoH zVixMviFzl2JmsL9s672a2YP1ykyLqtVv48vnrf9pQ9Vp7dfZq48K8/WrMSS/5o4v3re+CGU n00sPA/fSDuwum8f9ekZNNOi+bjd4wsM93kpr48uo1Kp1H///eu/fP2Xr//xb2qTeY6dvAU5 K/Kg9byRVB2d7urBXieTX6lUKnXAaOpUv1impDFYrxQ35OxfN23UUCqVSp0wUd8rliSLSZIU Jd7wWzled+gJy/W9Hn6g1s8b7jeQDzwdl42n9v7Xv//x9X/919f/+Hfv3uo6f5zU1zr2bbMb KKhI8sEZx2VzdSdyJ+1cdrMulZmxV+zHU6l9qNRfVx2Mv1PA5WYFrqVSh1Kp1FGrNwbcyeBm XVlLHT+UOmq1k4WNvf14ap++/X51uH4rITrWd+V4atOvrzSH1UCSDyJ2GOuOq+6q1RRVNtRl h6+ZPGeoutGAvv1mON7ghHl9hnC/gSRZCX5rVzReZ32o1F9XO22x8fBbvSnqTfNouKG+lhW+ xrKpSmrfb6kmwQF7Np0LDfRJbmqkDvc3hNRcXjtn3BAqlUqlDvtljs3BN6SsquW4t3wtVzS7 vvXMXaJTmloIb/n6rBhJ/WnKt1aXj1uNXTqOSp1obuQbW1dz2W3W2HFUKnXiCiPfFG2XnHsv Di/V7W7AL3PmHHrDlbf8dk37FC/eXNw2hUrt39jTxClGvtfr3r0It1w9e0jjY/2+o5oev5wm IElSyXp+aQ117BDNyAO/7T9n503ue4Omjwj3X5zetm22+px8S53g9N4FdetryXuu25aM06kq 5DItoPPhfk05/0H46T3mcw+/yVdUkyRJsu+mh237dmX4U7qsukVWKrx5YY+t4UyHMGXRg/3z DKzcdka9at4d/e2jQOM/6/u7Gkxb4bAu8B6naUPLcP/FqRM+u+c6XS6U6bz7WF/bUC6VPfKy sXDa1nXhfm119svkI8aTDjzgKYpJAq3K1AAAIABJREFUkiTlwhzavinUn/trzuDP3w/afIIt 1n4+t76GZJ7yWjlzRO9//usff/uv//5Hr94UzenuP1BvVwL/bavbtrDunPRfrL0gf1xou8Lj 6tVNegGPhI2Nm8L9kH3b9y4fQaVSqdRvqVQzl9hnrzt4qHJ62oXV1FGDqKPXulhu2GI3jtq3 /w8Tdt++mxgV42E6jtr0q6bK+nckI8xzxYwRus+ZBa5el9oYubaq7O6eKYa/NLb6duBAs5Mn rQzdfLwupbYoI++xugy14TNnWl24ZDXSLvhGelO/9STJuOG5wrT5wKtbdaUemEzabdM08LcD h5iF8a4c93Q3GU4d+OsP8wPviIjipnGjV1NHDtJ0OPD7wQuc74hyO3cvnfpqknHSw2z6cCqV SqV+98Mwsw8sqFtTSSbt3mjQNDvf/UA1P+VmZXDQx/vQ444OXEOSd05sNJhJpVKHzxpmG8+X Vwiue7iaDFeXYX6Kry2jppy8s0s7LpVKpVLHrDsemixp3W9dVSkjdPnyaYObihxENT8V4rou IixUt0jZ0+ioLWN1Oxwx29wunpQ3+y9bHUkyYt2WmwzXdtVqQV3+02jXzTo9TVnjeziRV5rm aTp6aFMRIwb9ZHdaqCggSZKU8Z6f8ZxMHfqddmSdrc0wbh31XaTteepaP88znzTcryNJ+jVX k2XDe/f65z++/vP//F/v3r2aRu83cNhEl/spDM33eJrCfee90ZE2k6nU75qKDHjSqt/KYnrI MhPNSaFSqVTqQo+Ea7k6jdKPB22cTv1h4o9GB+9LL/laL5iuHveHH5uP++X7/YT7nBfP79+g nT4UumfxkB8Wr3c9FEKj0Wg0Wsxl2t0cRv4HE+82yYQS5pPbly9epDWKijztZ7dk5bq9hy4+ 7ljAL+aJ069d3TlzltnWtXtjEh+/EWj+YBazWJnxtBOu5kOmWLsdP5uRyyHYAtYlP4M1u/cH BtK0Ap3XbbS2dwi4maP5UG0znzfcF/MKs5KuXIqhBWxabbR48twtB2i0c+pC4x7cf8HRtuQ+ Sj3vsW6x8QbPiOBwdYvTkafcbRcbrfOKufREu5qp6PWjR7cvH/Nys50+csc+J5OVy802Obsc oUWFh/mtnbvz1L1zd9LTznkFrxvbe9ioWZY+noHHA7ztzKdMWzDZZLPfkUCan4+rneFk98u8 Ai5BqBfFPbrBePO+yKZxabQz4bQ9q81NHfacSdS5bc2Tm6E77c1WrXWlnYlStzt82HvT0vEz fqH+eY7TJw33Oa+SI46sn2+xM+LISfXQIadP2K6e+GP/Ias2B9zM0rbMS4n222NpNn+ta8SZ xpk+FbTfdfXMGUP/rrfnemOR6nB/7qwJow1XbXQ5QKOdp9FoNG9XO1u7LUfOvdKG3az0+Iuu 81fv0oxLo0VF0Py2WK1Y53Dk6i0GoZQW8jNuJYRuXrlw+rDRBibb/COjzrtYLzJfMNV41cZt /lFR5/02LjZ38j57S5P4sp8/u3dD55qlHXa122i9zvLQPaG4jafsh4heZ6YkhHluXTvhH98Z ue0NvPbwZR5DwKQ/jrkUs93455Gz9aztQhOup9JlciVBEPw3T5/c0h350CGvjRYLLV2uirLb XDC3vXBfLhHlJV+Ou0KjBe/etX7l6Jnet9paUJeTfO6sm/US0+1eZ6Iimk6K25rZhlMH9/lx tV0nwn310b+6GOq2ffvWA+dfFcqUt8PWbnB0DTmZ2fJGY7L8t9mB86Yt3L4n7AFD8OTZ9e3T vl/oEfn4ab5uq+vHbbdtXLDxyL2Dy0b8uDEw6dYbgmgV7hcys25vGWi653zYA2HLamSCAkZ6 fHz6G17BR6060Ezb4T5BXD/u6eNoG5HW+GomYr5Mvn9V5wQG7/PZvn7Zql3Hn0kYhQRBEISU X0B/HH8x5uLh9WbmlgstPHVaX4lLepopIHRyNiY397zXEiNTSydX/xOadl5bTBeNHaG31Nb3 adPqrMnBkfbzvvlpzgQTx4NHw2g0Gi3syAnXzYYGrmFprzt0X//812mPz7gFrBn7zZBRc60O 7AsKPui52WzK9AWTTW0PHQui+e7dZbd09r7YAmk+QRBEZtq1Y64LrXdFnQtrKu/s6RP7bQzM 1vkcu/5M9w3IzOvHDu+0XG7vH3U+Wj07gd4bVkwdS/3PBS63nj7XafnopP3u7Vs2uwVpnoJe 9iYLRk4aPnTD8QJJU59SiSjv+c2Yaxe1A9P221iardsZfOO2zsDsB5ERrtbGZvb7os5HNI67 3Xre7GVTBw9ZuM3G9/LdZ3lCgigiiLdX9u1zddrirhmXRqMdPOCxYfUia9dYyZtOLGwq5Yvy Um/GXLhIo/msn79mxfsX1H15Le7wTmMz+33n1EXSwgK9d5lPGUP9z7mut2Oet7XLhxQUCl4+ iLlw+fA6U+st85dt8VuzZJrZzoDgUzSaj4+3q9X6C/8/e28d0Gay/f//Pr/7uXevrdzdLuxu 2+1ufeu6VdpS2wpuxd3dEwgEd3cPGoJDCO7uBA3uEggybZGWFpnvHyEhgbQU7navfPb812ae c2bOzPMkvGae866dnCYDAHoLckPsVET1bKKiMbQxhwX4IMQ4BAwDYwvbGXy2F4RZGUqJcSmi o9ZnEBvkZo0Q57hx+O+/oPPWOznaAzIs5DUQCBsvxoeopY6copKpSWwrg1bt5MQoqRYfm4zD Ym0UVGTEtwjqTgMw1FyUnuGooMJ1i/2CtFVUdGptf3dPV0dtfrSXg+bPfzj5WFndKia7hNgN wCwAJX5y5kikoQNDZG9La21FEVlTv7qp3vVfFcMD7ZlBik/FlBBo5wAsFovFhmOxdgaSwlwX Dp/n5P1ocH9yYoRUg49NxrnoCwqL8cgYYbExtG7Gp+fnN40wndwvt+H+7DDH2adSJraODJ00 cIiPY1wP9YnxnqY8SujoGLqzwCAfE5XHj+Xt8YS6IQAAoIyB9sKMVDMFMd47F+6ICIop2cQE YrBYrI25/rMnHBIo/HTHBymtfyz7L4T7C5Tn3RV4PB7vpyLyWOixiIkfnmbFTc0Du/qDc26g s64kB79hoY5Ghho66g6ZfRDu7ETgZHtzuJ6hsvg19TB8Ycfo3Ov1y5dfrT0n1RWGokXEZUX1 nUrbR+HaG9iQ6WJrrWXhyBA62s/RSlOaRy26ZHiGVf2b3/zk/mRbU0UePtrFy1ho3z5hpF94 NLWjWfn4utGN9xteT6/2RtqqSmkYOTuFUluk4fF+DoYqGrqOjlkbtGYJjI4Q89JSU9E8dxA6 sirG2kIS8toe+JgEfIiFhq2jh1sZGKlJzbPheXr30uknytpO8WmpbjrC3EK3+eW0LZzwMamp +qK3jTwT63ogXBfFtVW1snShxcXj8Xi8t7mVupa4YXgphDThv/GxrmhbnjuKRqGeYdRGsamp 5hqCIneP7r8l8FHh/uuV5S6CjTjC2M7Sh54cB3P5X66ffvSzSAADGn4xNVAYocrDJ21k74VZ b5qa4msiI3nn8AMJ/Y1ODiZGW0qcPXybl1fbOhwbg8fj8SGYABPpu5p+xWN9tKWzuvK2PkTO 2sqeFhePx+PxIfYOBhqyWs4x/fD5G7g4TiLleHkYcO377tJ9abRLQIy/I0qd9yoPL6+KTURA TIgTSl9ZzIjaGEII5ydnuyoY3OGxmABz6bsi6ISCFha06322NPtimJiXnGjB9f2NJ+ISZriC MtLo6spsf01Nkbu5EvetHzieeaZHFveMTC9ACJfmZkZq8LmZG5FTks01BESMPQtZl2b4ALg/ 29/YWIzHx4ckuQhfvGLgwkpQ9xWltzNcVUlC09g1MIw+KUgpJd6L5y49ubY7uA/h0mwrkeCi 8FA2oGy0f66jFuthKayPrB+b2HKmezLX1kpD7o4Kbmz1zWy/j4mkjLJ2SA4TjetsL/UU/LNg QFGgnrqggrptAG1TbRPc7wjXsEXqqeCmNvdmbRXO9bU3dbT1TO5cK5M13Iewo70uWPi8ZW7/ 1CyEEC4tPh9qL8BnE2gTGBeR5KIp9UzNNqGufpqhG9VF2ZGOLkjJgxxGQRgcrXUGIaOkmbzw YuOtqhUI69JcjTUl1JXRAfRlEeyC1nh69fIP53XSB9bL8Ey2zYfznr3Keeqxqp61Hx6Px6em 4H0QuopmVpiC5p0Mdenl9FBFQo7F44d3Lp3j1tBziUtKdNbkfyJ0W0BB38YFH5kYry94zcg3 ndgHIYTPlxbyAiQ0LJ18N76q8PhgWx09DQM999wBBinm50Otebb80rq27kFYanaSE50Qkrcv f/dA1CC8gKEPI9UpURbSArqeUbgkPB6Px0eGBxirPr54+K9PDXFlNE35NQhfjrVVVWYzBbbV 01DQ98ANwJe0VfZqoqs9TE1OTBPpHoRZj+tsLCEie//SzccinDqRGSVd5MU3byAE7bnZvvqC ep7R63HxeHxMUgJKlUcI4VNW2L+TPK73cQW+7GurKszG4yM8rXVvfS7k9w5BXTAwn2ujLKWL 9AimPhlTkxN9jMX5L317W8wIXcDqkvfZKoQTvfVlRZF2Tubyh/htPJWEZWW1DW398fiIxEQj SfHQ5PLBGQjhInmhFWMma2hFi0s1DxMlFR2UGZZxjw2QO7NCVPifSiNd/CKozVKSEnyMxUVv /vhQznyjk+3JMV7WkgauDP4iMX5mmoLP1AJqGbRqVyF8OdpaWZmNx0d4xujeZhfy3yKouzAz 1NoQ5xmjeY3tKL+MpXdCDamLPP92uq0yN9NF5vrjB3fva2Myshr7F5deQThcGY21kZK3xscm 0CLjMAlOmmLCavbJjcR1gYwVCIdKgs1M1DVVLQJp7YI8rXRk7964efK7n3QyPg7cXx9vRXZE gIPxs6Oc2pioMFr49Iys/NZJyhz92fgawlRHMZ5fDt3mkza0xuMTaZ000LJwr4Qv6HvNs33P c2yFVS1c/SNpzlLweG8bLXkNY2+fApp8yUxPd324h7Pi9ROcwo+fKpt4uYfj8fhwHFab7/J9 XffSkoGPMOJ/S/vPgftUG6zpTtX/+YK+Z3ptx68df3pioCtDQ+yOtJoVrmSnF1OGQLW5prab I6aiHwyPDxdgbSw8I/ILm0YA6B7ojNH8WcmPUNEIwHB7aa6/soqCX2xFByPf6S/Fxtjpm6Jd vGrBOItSA78C3KeMD9fEWLvbsJTARFvY+CcRx/s24b0GXzsdfSGFwArWk9JPTPHw1JQW0fSJ radfSyYP12R4qipLalr4pFcws9e2XJz70713nz4TVEM54ArK+8E0ebiT4JFY2FLZDUBbbrs7 98HbkoahlZXdww0EL9NrX5564uFf0tENGopxbkonpf36hjsAGCYmp/mbqGr6xDUw9JkyBqoi A0x1DJ3CgmmB+8sc3Mw0FPVDsDWA9tp+Z1t1lLuqwO1vP3lg8FHhPqky0V7n8mmZyL6q9Q2R odGB3Eg0ysI6HFfIoBfdFBVoqyemaGGLrRmnIS5yd0N1BFL5zrd8FngmuM/5y10+hF18eff6 HlJTWQDSSklDJrp7hHpquKu8ONpRRV03oGC0k85yp8ZBJyHaw1AP7esWRzszXu9jrSV1X8DE L7ubTJkptOUSf3zvgUZQdvcUZaYzUkUQZeERTHzn8Doz3RzUBU7y+dYOk9cnYahtIC/QCo1i vchcAgNyuydolGqwIiFR89J+Hq+oss71U/OT/aDaVIJTWN40MoMltadFrktzMLl78qZVXWEr KyL94TX32xMTnPWv3bHJZAH3mzL9rZEymtp+2USa3O54V31NpAmK/+T3Z6SVdwv3AehrSHB2 1ZAVUrZ2cOSXkHBwia5u3dxmcLA9xeXeKS7d4JCiHgAG+1oSkGf3CqNiYqoZ3zFI9dXQVuY3 De0rTkbcERGxscXWtm6B+8OkRozgfi2fzKTmXfb4HcYa7hPxxghdYx2brO531c4eqs8PQEhf uyAdO1q3aVPjA2ruj3cVlEUq8PMZIv0LS1o2skFM9bESeyQmwQT3g3WffnlFWsevsKl7FAAA xjt7CkONb3PoR5Vm7/T0fhOh3pl7300pk8j62t6hmiQn4+vf/PTEJ7SquxfU5mGcVC4pBoyS uwHoLA0PtzfSMowrnpyi929qrL8T7+Kqp4r2T0lk2Fgo9lEzluUS9OsmU6gEc6izloC1RSGM gtKauxn7mKJ/TV4TiUyk3xu9dRnhwZbWVo5xJZSpd0oYT42CTrwl71VpPTfvio1sEbwtEHLa eoG5LZTpyfW4CRgEP8+xr0/J+Ptld9OuJXiY6qFdIpOrGO/JjqZSjJehhqxBcl7L4G7VkwEA oMhL2Uz13XC/yMvfSPaQsH/T5BS1Htx4R00l1hZpbOSNb2H1FsSHWa27qYrAteu88qrWhkEl rb1jAJCaavKxQbntUzOToK8e5+1laqYflNs6NUOvQ0ce7K4IQxpqGrhF51bT99iIYV5oHQlV W0bZ2/GO6tJgA9nre3htCnC1AICBIRIhXEFW0y0pjanTvbXpGE8kSgcRUDY1zeKNgEIPXzPV LXCfZqTYKEuFa5dV/VunetZ7OdBZF2N04mtBdHxc7Si106Ay3MJQwzoQn8e4nTVUW433tETq ytiVETvHAABgoKo5Bc3LLW0alF/WRp1SCgAdBWHORjznb959/O9Sc7/UlvsPR59KWHnl17fR O+kirqbnbB5F33RpLAp2tDO2NUlgPH0/NtJTnuZkrKNiHZxexrA/k+iu9eTe8TvcSsHJbTND kwAAUmOKnaPIw2t27dVdO9y6/lXtvxDu063Tz1zNVM08peMjdOF5R1QQUunBPdtcCHdcYX40 JTXMRcowiwzhW9hbT4iMCEpIqJuGcA3Cqihzewd0dBWEa2urvbm2nhauntF1jBLAC6OtzfGO 5krKLoVDbSyo/K8D98fq0vGBW/UvqeYVW0TafExtqqYl3vT4cVRyB5nVpCy8HK0qQPErqtl5 Edo7169dg3CKVBDgbqytrBtQRIZzDMRydWU5U/e2Mt8DHgUEwieugAzn3sLnpPz6iqKcHghX V2CmrpaiJJ9JTE7Pm9XlkRiZk7yPlLWC6nrgi5XlbKvbCq4xBXUQvnkxMlaAMjdyC84gdTL2 eaSmNsbFDGllXkQmz72FEC6MllRiNfgFLfzzJmgawIurK01ZvkjFG0fv835UuL+w/KbGi/uS pmUMdn29rkLYXZMa5msX4MuoFz3T1JVlL8CvYuRfSOxf7yVVQddP466kqjET3EfLXD4rquJT SJyeW4QQwumpztQYwduyftWFfYsQQrgwvdyMs0bqucdVMh33fN7enOvvYGWu6t02Rj0zTqki 4nR/OiFkEdVAGl8cLgzxkTjBfgeFqZkYX3xOTPBxlnxmToST7wDYC+Ot9c63Lj62CsgkrU/C 6grsyU4L92S5wqxtbL0IpE7y4nrbt0vdnlxissbaIfUbq2skMcpS9f5dBJYMn7+zcsrC8lJ9 pNRFMb1Aj2JWJys/vOb+/OBStemTu6aeLOD+9FhHhrugoIZ9fBZNbndtZZlSFR2N5Hl46+m5 3cJ9COefD5ZlIwXk1Z3MbDWMEQhtk7y2zfoiqxB2Z9soqsvqacT3QbgKYVe84TNVKR1UHqNW bWd7qafgX4QDSI2EOKSNqoaseWE7hEtb4H6lu4qjualz7W66+25jDfenu9JTfJTvieLqR1+w zs8SeN1HMH9wRsk+KX7TDH1Azf3V5ddT1WhbhJGWZWJSw8bameqsxNurCJ49b5DBCPf5jlzn 5zeJyW4cp14MKZU4hKqJpW/oTqn020WYrqYsKyVskVDQt7S00B0uevDpYw3DcGIfnH01l476 WcY9qbQRwnlKVwNW3Ug7NLGOSQMZtGZn+ZpbW7r4kSCgbSBPthWHC/79iV15fhc1W0vLbwYr I129bQOjc4iMfexIdXGSvfHAjzwMqOWX5mdH6nI8LewtIzJamcWWNxlozfXQUeLi0yqElPX7 b2qkNc1NSFjdMSm3e+LletyBighjw6dnObjVpENpL3KA9rIEX0uUfWDxxPNFetmn+Tev6tI9 DFGo8Ijs3t2qJ0MI4URzfrjw5xJB74D7E83PMYKHntgHFnZTv5RX3y5NVoRHeNt6xuTuZl9h 3W1JZaT6iVOcUpJGRp6ZeU1kCOfeLDXhw4uaeyZfwvnZvopsMw1d97S8nknGHwND5fEYBzMz B0zZJHxFTcZUXXOqrZCwJiK4jC57u/r29WRFuIfSTQktK3QBpB7Grwx0dLINcGPq9PzMcG2m O1pXwy2loYfFHim5aTZc+EeJoC1wH0II4VzP83LjuydFUJGVxPVeLkPYFastoCxnZFFAm5bh yiyMI9LaI6kdztP3lJZmXg9khjvrGDilpFRMQAjh8mvYFeZsqq9jE5W6IYg9O1BHwBhKcJ/+ 4pQO4d+l5j4/L98NBaPI4vb1TbLZgSLfABPlp3Ydk+t70RRyOyFaQ0sTU9E4Qn+SrEI42ZKB 8TKzt/FM6djYYGtrLDDj+fZ7jifW3lm9fS8hhHOvX5SlKd2QQsUHV859vAH/W9n/ZbhPoUx0 N2Qn4RNwNIvA4fREzgupIsMIO/ZGBiDRWhpp75xYSWnuqUbzfv3p4TsINLZ+jNzQXWb98DY6 IquxH5CbsyMdfjkubBHsHobbbE5aNgbKj9w7B8a2Qo5fAe5PDPfm2AkrCT9kZTx8IroepcOb 6w1sA/cr4uyM9ES3yu1OAdCE1RJEmLh6MSu/tuViXZ7uPcXvHFpGYqGI3Jbb4Sd60Sgzs34I ANCWG+kptJffp7ekAwBAqkoOMr4h7T8w3AFAEw7tovrwrgEOE7UljR6qGjpoDaeiYTAzA4bz bUXNrdwcCjZFGh3sINjf+kLM7GOf3I/0VBRUtwn3w6z3Li4xBV/V2z/KtIHTG66CtrTVjtoi ID3a1xSq5pVYnU0tfkOF+yKm5r65TE1LAxJd9TisKqg1i8j5XhgTkZMSzmGR2C3ZMVNXR6rp Ybuo9KTex9rKQdkyk+qm3ltMU99YmYbz04zFbB0Z4X5ve01BFqMzPxOEksTZW9aEwfF1Mt5T 3RljKMDzhOUi45Uz0I9qoe9egJ6y1nC1M6f4UbEV1SMAAAploLYeffuBoBkivJIJyg+1dVQy RQ51RpgInT2hk5HTyOpc5a8C93sxzihLFZ3olk0v04x2gXjZBw/UNXYP9wHoKy70N3h29tyx 61cVfYtzt6B9MF7bloO89fVtg+DikkEAABjvacpSP3hH0toukchwm1Lhvg2WMkwhhug/4JFD eoeTxrbA/WaM4FmzyNxMajqmJ8FQfWlmahJDSlNLWlr7d3p2v5lU5yz46XUFc2dXBlc26kLq Jk5emRu5J3c3NhSmMM6gt4Wmyr1DXH4jlZuqaG0P98mkvLBQJU7xyLGaLWy3MSU8PtArppVW LqbYB2OtfkY7jVE9gtxDLEWcVvEsfF8hNJbWRCD6SJ02yC1sGgEANBEC3Z4d4fEfqeoGALSV Yv2Q9xQDx8jdYDTHTQ8hyiXlgouO3XILmvKpIN0Q8RugvDHFyctEVgGNi6Hfr6nZ6ZVdW0uC lAYoopHGBo4M3gilJcTN+2DTE2NDdRmZqfHMYY+LadnZ5dAa9YTYISw0DGNbmUDqSH9zsuvd L28o+a7D/bFOkKXxVEBdzchty0hCgnwtBK9J+mTXN+38pQ+6bQP3G5ISvUyeKKCjGbKTSqhs m56ZZNX8Q63W3VT66X1eQ49CwAqbl0YYaqjyyBjjcFufoW4KPFrW/t5l1FdOQE+wtLGFizFu czW4yUFSY6CCW1JjQTsAk3VNhTb39vMbO/gEbXHoZWamyydk3UIhbR3S++E+qC+MNFe9co8v qLmudxIAMDlUWhqvffW7R5bRNbVDAAAw3Ucc8rx3X8pYw5pFZG9v3StXrPGVHaMAjFXgsq34 LprXVpA2/8oo91c3kPt4J/fp9mFwv9yN+7NnXgUNTI/fWjcEykmPXjNwJMpBQ02cV88Vh9t6 CyK5uEy8Izf2yECiu6qgKJeeXRHYeH2iMaXGW/aYfmF5266EwX8l+x3uf5jNT3TV1+YRGMzN WkOJ56LBro69Nxfg/HQFXEohnJtPcpe5efHY44dW5S/W1lYoUQ4mjqZ22SNweW0VJKne19Uz RmEImy02ON3wGp9DGb5l6/T9OnC/K8PLU+vpO0zOIrq8etO53m3g/vhQC1brOKdL7la5XUpr qqezuJBOGRxlOA+8urKcqXtNRFhZN6yGRQ2G1RWYqWviHGaJH6Y1PqtrGxZYByFcWFmu9+ZV 8U0qqIPw5WBjkdZ+fn1/25AtaYxxDbRTv6GQ2Tj88g1cHCoMjdQXkUmHw0yocA3CkQwrIV35 j35yP91a2crSxZlhuvNqu7qZefk8MbHQWfKKU18PZfMbI5SKiKwUHIZ2KBcOJka7WvDKRTG9 XDLV+SZagNsqK6VxBkK4PNE+7f+AU87a1DN2S3YCAwJMbt50r+qbXoAQUqqIaTanhHDdQ88h hJSqaJwp1ylzIrV7XYSoEE1GuD8/P9tdRyBk050lYlJcRS5fM3BOaVxnMavLsC7IHSHLcoVx 8fDJe5dX99FYyepbWOdqKCMnicTkT0EI1yCcI6eg7NSU7htmMQ1waW5lpK4kfyNyelqKv9Jl bk0XGwIrCvSrwP35huY8Z45rzqX905vpTmOgr6Ha1d3DfQhfUd6Qwiy5H9y6fo0X4cWiGNjq WziJsRATl1H2SaLt0HSEqyOUJHkcql5ASKuUTYX7IgGkkYHJ8jR7A9GHirbdL6aXVrbAfUNv e7tgeuWdxfERUnUBw8rIKScSh3d6dp8K92VkeXVsGFyFuqJNtBS0sf0TtMP2y4vPZ0lFBTmZ 9DZpyQnmT/dJorFhjcwut4f7y8uvySUmD1G+hJi2zZ89H+ouctTGEicHqHM22TYfKXRWJSq+ kul5MxCn7+vmiMrf6XAXYbolOlxtAAAgAElEQVSavlMk9Z2kt4sv09WOaDlgwxshhHOv56vc fpH3I5Q2wqXx5jzfR4dkbEN9cFtuQX+Ur4nCPe/x4dllWp+JeTb3NCwj/SJpbTIyCdX9Y7OL m+KPVONirSXkrAmxibSWucXZjeMLW3RGFsfb26tzmcPKqwtxisVDMjUzc7X1Wc6ct9wqRgDD 8l6FcCjbSlBOXHED7neE+1vr3n1mu2UkeALBz0hez8otoXrnL33QbRu4Dwbmcm1E1S1d/Dey QyBUt43P/lMFUyZKKkOVTx3kQMSPkihbPx7uKgvVOnrHIDxq6xd1lIOJjbaaZu7LqcVVCOFc TWSmswKnx8Dolt3IiZLA9NSUmGYIV1/DOayVnIaKvFXQFocpCQlmjx7ZJBaWbh3S++E+nF18 nmF/+7qsWSy2+QWEcHXl1Vyfh6GIlJpBRD6t0NhirpUzUvW+DovIBAJKVtbG2b9sGsLVVy8n gvm1HGN9SzZv1lBaC2Klv7tq/JFO7tPtg+G+mAHaIr6K6dLisnj7K1JJ49QKR68b6zLsHh+T coiMi9sybF8EwlRV15cMX67fN22NeZaCe6/oJoy30n8CvX4OUxU1HWI88lgXbPvvs/+zcH96 arKTVB1qdOOHs/u+Zlu3r9nYPv/bn67x7wbuUwCoDlbQcnAJS+2pbIuRucj+xWffcsvaJ1c3 5Ta78+8TDUos7QSgozrFVvngH/d8tedLelhGO8l5Wj2hd3grKflty/LQbRu4jw+ys9N5x6cN vpI29q4WzP1oy032E71hlNlXz7KSwwfD/bJAPfUrn/z5c7avWabxGBe3XmQNmJwCZb6SvPpG bkHEzaFGu5sjfgtBXVJvm6fSsR+P07r27Y8/nVaJjC/uYKSNaQhOXUMzGmN/t9Fr7kcy75kw w31SkrUV3/d//PuXe1gmh+36fSnnRAAmwYfD/RkAyCP90Z6a3Nf+weDpqy8+Zz+975Y1ng73 d2aDA+3xllc+F0DEY8qnwExvHzFC//SXohZpWIZS/2ByZDjTw1fx2udsbPQB7fny8z3f7Duo QfiIcD/VSEvHiNcqa/MlE32gdLeCuozWktniK3HWMCeXyGII00RCpfWjvx9VsozLq6BqQTaU dXpwXbkpq+ieXreBQWlwHwAKAJmWj2TkVFR8Kztb68KY4H4TRvCkCSY3g7opNNEPKm0UOc8d YWNj2/PlV5//9X//969HZfyC8nu29uS91kyqsxX89PP9X3z5JcO6OKMQGMLgamp8sCbC1Jj7 0JdMa+cz9n2HHvnsAu63lcU66t/g1M8ea9pSZGizFfvEuhjcs6tilK/++HC/Lt5chGv/X//+ JRvrW/CmgoJHIYPfjsokO63zbN+x05b3Cc5ziiFNpMHxzTC1McVBXvQkQxp/Fhe1SuoZGJuk CerOUCYGiUWpOheunNi7hyHmF3/94zkxBrifrKeqhRDe+DctOd0NJcYnH+kHr8P9oTYQxn/l p31//5xx9ui2l43tslJwecGuT9BvC/cBGKhIwGme3/stPTsnT15UdmnpII5TdlnxHwBQ625q 5qhtv3n4NEv2Un546c9//5zl9LGxHec3QeHWj8En61zWRDo45r43XF9xPUb2+Cefsn351R5W Dn88c0MUM9nQt+XCbeA+GCiLidDh+OSBZ3p19xSY7i7ABCpf+ZsAJrdu3dd4Z22J4fFTP379 2T9YRj7IxiZqU9TYCEBjqreL2AmuwMmt70O0xn7Umvt0+zC4T625X9rK9LTaBPdrXBH8l/f/ lfWqZWNju6Xq611MvzjRHWGN1I+qZpQX/h3u79p+U7i/BuHbBVCFNRHmOfI1+4Z9+Y/Pfjq2 S7g/2pAQ5ihqEPEWTja5IQUvfPPlhTO87pVvVp+n66ga2WuGECFcWF2t9+E/cWXv518whqXb N9+yC3jGlA5ucf7bluWh2zZwv7unJYTvOCqT1adT1dh0GyGBWMhYM2l1ZTlTl9c5NAHPklR8 MNyf7qqO4vn/juz96h97WKXxwLnvbjmm9EzOwqFqrKPpUxGzRjixhcJWe/82NfcLwnT5ORl6 d1wAhY5rY9Sq7c708Za/IoSDg9uSE2rNfUQu038yw/35IWIN4uixA2xffMXGKjvH9+5X9Okc HYI7gvtvXi801GWZ8HzO/iPdK9vX7F999skhZSs63N9xcrpTUbxq0pp6hCW4tgqXm7D63MrS eubFDK2WX78ZrB3y4rl0+kfG2d7z6ScH+G0+ItzvTC/3UvhEGEca2YLcBhN2X3N/Y1xLkKBp 6BRhl8FiCGvLr18nK4vyyvIjoyvoWpDpVlYK4mef+Va/hYvrMsYMcB/C3lx/N4VrFwyL28YW Stw2wX19TzubAPpzcxgfbylygZrKrz7961/+9h2Hgkp039aevNeocP/Oxb9+9g+GqTn2WF2d wdXKm8WptkK81unTR/cyrEi2L/76h2tau4D7c0sLle6P7ph6EzLfVaV9w9t6zX1CM9Pj8CPD /cn+2mCDI/+7l20P61vwBMdhNXzfBB2qzy8tVAeKXuQ4TGuw9/uvntphstqezy8xY/upwYZI y2vsx/fTknjs2veSmFrS+PzSuiI0Vdm1CaOj/fgw0/3yxac/nGOA+6SUQg+lT8Xie8mbt64G cHqWpgYbcL/c1Unywp/+9g921nb2iZYfdtcn6LeF+xCuvJ7rChAR4ThEzw77V0+1wnPKni8s bhFP/+CoJZWJdpfEE0YmWO5LtDfno57+z5+/2fM1yy/qHy8/fuzePg6WIITtSQ7uyvckEyFr T1RbXoRtLloPzu7/lPVXFjs7+yMzQsKWzart4D5cfvWi0+vRLxJII0zdElx9uzjdYHPrgawl KnbDVz9WS+vB/r989s7IMvaJ5RAuzc2mKR3QcEqMbtoc5WXPR625T7cPhvuaDi5uzCXZNsF9 clGZr/iRP/7966/ZWN6CpzhFNQlwZn37rK2xLFD8ml3R+PON4f0O9/+V9pvC/a6GLHcjjsMX lcKiM2tJ69ZIInlp35bS2Q3cnwWAUu2J9A8Ic0tOTzE48/UjznNsF2SU3D0T0zJNbvJ6tBW0 TQPQUZ3ipnvhkgqmYiMso3X1dA2SWWm4/Q73N8N9tMx9IR9SXROrNHb29g2NU8Dk7L8e7k9P T40OdHZ20rrWUFHoI3bwqijKMW4DYP/qcN9Zm++KYVptYyur7HT39I+QqRTjQ+H+KAA4a76f BYSQyGgGT8XBgWj1y4wn93dmM+Q+Yp7+qZ/FLKyxdWCwqj1B/+rnD43jS8oYX2zIsjYVFLgl YOJLIrXQIlenBQapXD6ll/nfCvfbczAuv/z5z5/87bMv97BRtSDZvv7miz//6U8H72r6R26c 9GeC+xPDMe7q4uJPDKzxdYH8jHC/HiP4hbwjHkutST07AygjAz1dnSQSqTo1z1/5xDFlF3xN y7vw6jutmVTnJvjpI9MIPIHxMTYwxgjTicFKCvyCj1Q88CRSG61NfpSzJd8h7t2c3P+PgPvK WkJyiHRSSzurW7BnYGCU8ZD2NIU8MthF6qB9XpUW7Kt0c/91VHBZGzNonSKPDPR3bXgqCkEa i3NdEvEsJFOohVQGKpNi9e58d1bVPim/nCFmqPJFZcPdwv1nKKRfBquRdJBI3QNjlB0vHAbb Fu7PUMjkwa6Ojeyk5norXt53XTOkvOifKcuzDdxXleczDWBYsYzW2Tc0TF7v7ofC/Wjd44eV XZMKylk67OruH59lAfC3g/sz3QWVAUpH/iZol1tHBKQyLEr31qn7HkPV3evtqXD/nqqbU2wF y8gkUv/I5NTUfx/cl9d4puRFYDVmEonUMzDKcAv+Dvd/VftN4f4ihK0Y+WsCkghEeN34hmXE OpmI7xLuL09UZmTZGaBbYanXMxGZWwdOcQieFrNpWS1zF0J7Yr0r3tDg/n19dACGMSyjTc8t LG0lFr/D/c1wP5r/D2IOeXFVLJM4MU55+ertyuq/Hu6vQfh64fk0haFzmS6K8mLCXBsiub8+ 3K81OcGpgwnNaWeVHPL4+Ozc2+VluCO435Afqi51+Y6g/3h9J81TT90gQev+bYTbLuH+GoRv e7B6BsrSd9AlcHUZdgegeKWkNfzTGSvU9OXXOkntZxeyKKmvpkUeHR4str4vaeT+3wr3l5cW 8w3O3Tr41798+iVdW/LbPZ999rdvD1yWc2iDNBljJri//Lq5IcucZ89tNGEwGL0J7ktbGeuZ F9IDvFp8MTM5Pj4+OjRebKkqqqWCTmpY2CkrpcJ9NW1lNxzjCpsCgMHVVG1cjP7jfVeMMTVt JFqb4f6eCNlDKrb/rXA/yuTMaZ2omgLSOAuboJDBhqoxhKtrq0vzM5MU8vrnI4O9RfY8fHzq Wr6bCs+sLL9ZeDE5Tms43l2Tnap/9dx9lHcBiVqWZ2VpoStQVJhbRtoKW84QsyTM3Fpmt3Df VOeGbjzLR+34+MQUmN/xwmGwbeH+2trq2/mZmY3sDIwX2erw8olr++N2XQ99e7jvKvSFgEtV cy3LZ+jk1NTc25XVNbgjuC+up4HGVrwjj1MvXi1uLUS2Hdxfe7v4tt5G7YGsIiq2As69elHu /Xi/BDI2rG7DVz9Wy8xQU9T9nZFnXy4u/ffB/TDjCxeMccTODta34Ax4BWm34O9wH8L/u3C/ Py870vIRDwKb3947Qo82BkAk6qG8wW7gPgAAjMaburpYCupZWt77/iYqUePJLWkZWSE9e7tH 19Xieqv6AQDkzmJsiMzPD+wK85p39Bfjvyfcr8DZGemJGvi1bC3L0/yOsjy/DtwfynQNQEqe M8jrH31PPdwZAIbybViX5Rn6LcrysLCpif6OEiOZ+0rGDon03JS7CMopqkl5Vr3vSvChcJ9c Ex5lq3ZNwL90mDz+focfCPfJvSBbU14NZepXwHS2lJSU4Kx/9ZZ1xi7hPpiZHBiqM5d7IKSG iIhMjo9Qv3CK3xdb3sXIbMsd5M2NUKi4xk4G4jNQkZCgf/W0/seE+71hTiiLd5fl0di1oO66 vQfu9xVnuBtxnbivFhbuj2UyN6UHvLL6qsH0EvdMcB+A3pIAA30x4UtqgT5cf6HD/an+VpLD rV80vF1Tt4jI9pc34/TPntIPzG/aJlcs7F2CunSjAECMUpVHopx9q0jDDOysOSPYXeQQj/9u yvI0pPlaPTl2266itH2bBf4vgvujVaEISw3ZZ0GtE+9gsu+3yaGG2hRroRO3UTFlZYPvazne lZPopid6W8yhaoJEBgD01iYH2/IIayaWlQ8yKSSn6F/TQnxQWR43xrI8lD5Aspe5p47ywO9Y vPbDbFu4v9kmh/qrEr0Ff+JFYSPfn5332DZwvyfNVtVYQcW0EGz7ckCJ7WNxRT2VgPemZ7Kt vdhP6vgtdGzlzrq8HdwHk4NdJXHIq3sFrKJxOP9Ic/mr9zQCm6d6aeR6erhtKF6KW9DCLqp8 c+UgZhuriM2y4r2I/rcvy/MhcH8kK0BPVVPRIrQNsDgssdl+h/u/qv2WcP81Bfb5KMmZuIQU 0iuAQwghrMkNspHbJdyHS6TsBn/lOz4lNnxnJbXQYmpmqCfn7ngX2/DdN3OLi+uBEC6vrYIy Cx5tC1+34i3Klu+zf0+4v16WxzWPVVmeNC8XCSGd0q1leX4FuP9mvG3I+dot3djYyvdLuS4O FoZGUMvyMPVwDcKRzI9eloe1gYG4ELSO8BNnuurvWCkmRPP2fq1S0th25S0+AO4vz/ZO4+We CjsHZndss8g+HO53RuK8TYSN4urG4AaBmh9aqjblumfqvku4DyGEi+PJEbZqvPeNoruX8h2e yMghkGENjHUyxopwOH0RMe/6+ulF+nNt9e0SyZNLwdTzY5flufnusjy7FtRdt/fA/VeUpXaM +tXHSqZ27ngmi3I0NJLkOo0q652kJoMJ7kM4TyFlRoqcuqYbh5B6wAj3ZzMsnM0M+Ny3cLvV N7Dd3VDeVNchs3vzZ9vauwR1GW2yKSHQRVoFWdLVt7BEr/j99tU8QeOYlsNuyvK8fTUeJ3tW BuHtV/6+7woI/1Vwf2mmszBZ4Ry/S2lh924K1qytvJnri3dWkNEz8U99L1pcXhifaPBTv81l HlZYMQ0hfPVmoS1KQtTcOzqxl0khuSPVxUNpc1meO7fcKkcA4xMawuGcTWV5ZtOj7VDigp4V /8xqf7dtC/c329oKfNlb4Cinq2eq//7svC/q++H+3FBdsiPnce2UoQYWRXuYbDjP11fzl+OG FUPT707P6hv4stBXVRmJCtpZl7eD+3B1Bb7sjTMUUVEzNE8oeZ5pcOe6qBm2upnh7llo8PU0 Q4oapg3QVV5Yenr1YiKI751leWT+ncrybAv3X/e0ZvsoXuZ1q5rs2/4W/B3uQ/h/F+53pKZ5 6l++YZnZO7LO1YZJwwV+NhbCtw49ld0t3AdNfl72qhzXuXmPXNdO7010klGTvnv4tpjgFUnP ygHSBAAAkHuqqmK0nwnJI30yCpnPnXZXpieFedrF1o5ObFXU/feE+32Nye4eeuoSVjl1o5MM urb9NTFaWnIaaG98OXNl/V8L7oPOsrxQa34hSaOA/MZOpjT2l8ViQzH+CRVUMc++Ens3MyMN k4ScbjqmGe4h4qNQQvf2fvJwq6DuMJGYg3FEIk2RSJ/Uxuqd1ilhtK6K6uwEB1ztGMOETpP7 ujI1RJ5qIt3TW2j/2VfibaMrLSiDCsjpntiASWTycH2ml4VjYGoWtR8fBvfBcENFnLu2gKi8 fXxWaz+T1mUTITU0zCs8p44KrD8Q7o90gXARLllb08gNSc3+0pgYexkRLq6fblmn7xbuAzAJ QJW3OKeUvLKoPkrr8kkuz9qyTqayVGnGXDpGZtaZG5Ebc2L8dUREOX86pv0xa+4DYoafNVLZ 0DC+bkMnYKitn+BqKXz6wD8lqAsAeB/cHy7x99ETPclpkzs6sUmqtC/FUF1Mllc9bH0GN8N9 MFQfH26veOPyXa5j//vUbB3ug4lhUBlupC6vbR2YVMlcor2zoDFQ7vuTuj4fBe5PAFDqJcKl j/LBbGwrEMuSQ6wkeLivHHrqywruq6sIK3rl9QAqSBxuyMoMc7ayD0pppQxMAgDAYHNGiisP xy0Z28g65lPGxNLk4ADXoOC8nnUK+a+B+2CoPi7aRV1IwsAxuZU0yFRJnYj3Cw6LiqJrm/YV ZyWlYVOqehjB4mBNS6LZnRNcVglVNdQVMDUGOglRYWmZZW1McLiDkOys+5hTybdponuS2g1H /VsPDYrIzetLZ3CoJyfCHCV3fT+XCgPcB43pXhYIVQQyoZ4Ojgdb8tOcBPmO7zlNF9QFEwBU puip6CiZmETn1zNS1/HO/uoEdzNXXElH2z+hqPteuN9Xn5mYFpua18OIaAf6muKdbv8kapWE q91t4G3gPiAVefmjJcXkXUNKpno36O4UAJ1Fke4hESmpNEXd3kJXMw3JZ0pWIfk9DG/djY/2 VaW7ouyCCPn1fQCMj3YVpRlwyyua2cWUVzNPYVNZXJida1jZdO9WjLwt3AeA3FlbYfjTdSG0 tryIkQLfZRVcy9T0xpqjjICONBdVORUde7fU6l7GZTbQ1JUdhjINy2jv6wMA9Fc2J5vz8Mi5 JDQxbuI2pnpbil64dW+roC4ZgMpUbydHJNLCPTQ0v3dmdnuO/l6rxSKUNMTUTPJ7p6muhuqq 00OcbZyd00hdQ9QxfRjcB721MbaO6vLSiLBU0szwxs8XMgCVKV6OYdjCgg1F3d/h/q9qvyXc XxiFjab8j0zd4+s2BEd7cwmRRtLcApy7hftwpqYz2/gGvzLXgYtqdvFhybgEvUt7+JQfnBWy DsqteQ4hhGtrq1M13i4obQ3zkIQ6poG+mh1vjbP2iitr7N8a/N8T7i+8GKnKQ/IpmcYl1Y8z orixuugwW20VHb8CFoK6vwLch4vTK00xeqoKOvZRmQ1Mf3svjLY2Z4TZ+Be1Tc8tQrgwWlwR o8Mv4h/fMD2+vo/zZnV1rBaH1n5w7MFWQd03L1bHCnA+ro5WVt7RWfk7rVPCaIszKy3xgWn1 xAEmIPK8I9Ifrc0t4t9Kg2ULI1Ul4bq3bj2zjW1g2G1ag3CqowAXExYdSu/HB8B9+Ob58kiO p7qitqlvWGk308TN9IyUxNnYJlRQXgC4E7hf5RVkaXgPmUMXAV4YaWlKsEIr3z56Qcfhn4D7 EI5URlno3rsuEJFjwHFOxigwpI6J6nYRgrwUHojETgyvl7ReeE4m5nmhjbmO3lJw/IhwH06P kQiuAsLawYXV9FcqVldgd1aq9bNHd7j+CUFdCOH74P4bSsdAuMDPNwzc8E2bwNJ8R3q6nfh3 5ywJvZTnEG6B+3AJDAxkIUR4xZ6e/V5AZgPuw+Gq9EBrOXVEYMkE47F6uLIEK8xVJfSVPxbc HyjH2JjySVq1w6n1SlTTU0PFMeYouZ/38JuwgvvRRmfOa8fWTFDftlkCY8N5vl7OvnFl3T0v IYRw5e2rrgxNHXlZTcvEIqaT7dOUwSKcrX1ARmc39eJ/DdyHS6C/PxOhLKtuHphX0cu0rzjV WVUU5+eYTFovzDU/PNZSGBRc2vN8cWMtrSzB7ghLeSUN8/AN+WTQTiwtjE8jTkC4MX/zIwu1 LmK3RS1jyhqoQqDzFa4PbpsGZGatC+yuQNhVlRRmLfZQ4BED3IeU4ZY0FyFRrdCS+uHn603f vurKMDcXPMfBrboB9+FwR4qfp5SyhFNKyezcc3ro1beQUpUbE4VLqyT+E4q674X787MjzYVB IYU9LygM2YGwKwMtq6+JRufvNvA2cB/OTTTXRAjJSaNc4tpbmHaQwVBjdnp4aGjZ5ItXyxDC +cGSnCDtu/elHZNa+zZ6uQohpS07KhKDiyoeWJdyjbF00tXVckrbEOOFEMK5pVcNGd6ucTmk lq1b1dvCfQghhENYbaSy3F1Jazzy/HFhn4jKIaY1N9tShHE0lNfWDS3rePlqI5HLS7CLkBAa F1fYMgAhXH4NO0OcUIam7mklDK9EUEjlaXbSfGdYCuoOkcqTMFZW1vZO3lndfVPMouA7tonu MgzywhW1BCKR6mpp5tVATqSbo29CFU2s5cPgPpyb6c4nIISl1F2DC/v6mbZnh0hliXGBMakd cGF9s/F3uA/hvx7uT/T2EovScLg4HA7nqS7Ly3f9vroTDheDw+FSisubN/7UHWsvL89JwoW5 BqL4jh7iUzJ388fhcDhcXEIyvqqn733Ht1lZf2lZqIXcDWGNEIwfVWEt0D1ET+De0/M/7LnA KWTomFPROMxSZ+/9lhfpIH3vwNkTp/Viuof6KpwtFTnYf7h66r5zQd8obSyjYwNFGC1BaUUD hEMAo8ibO1pHRV5a1CF3cGwSAACGSZ1VdBFRcy0BvoeXRPVxOKqCbHpR/caf3331tYXpOByO qgksfO4+v4gOmnZldnV3xw7JK2Wkt7syLSkhDuehKs3Dd+OBhjN1UnC4pJyKCkbV3b7S0mgH RQFtm/BImmQsLjIsGCV1V9k2On4d7U8D0Fmfn5GOw/lam6je+knAIsR9vXVKUmp5y+QUGYBh Um1VtLW/6q3DAhYW/lkVzX21uZHuPF/dVAt2iK2p76itSvbWu3hXMwwTW9PTMQJ6a3NiEFx3 xQwcPZl0Aj2Q8ooKunpu6c3r9LM83d/UUEJJ2xkXRR0Dzt/bUU/mDseF7/54QQip619c2Lix BUGujYjQ52D7///4P3tOiDnmZreA3VtZYDhSeM89g2AG2d/o8BBHDR5RIz8Mk2tSSbS9mbyE oLZzRBRdwTE0PAStzv2UV8sPk91CGe7pKsEmujy781RRUS8gq6iRKorbW5dX4K2OVOA9Keke lljR3D86AcBoS3GBqywfl5Khmx/TIrPV1JRSlzWPyKGQ++qzsgLVJcRlfhG3T06raKFMVXiL KcuK/qIbmpJL7KNMJxnz66sr6obm5la1UjKsVcUV5AxtvOh5Rsgq8ly8cOb83lPS5mGZJb3D 25ZIeWeePERVpK7/dJOb84yUZ+loB/Np7LIgVX01eRnDjci2BgrPrl+4dGzvXm60VUQJdXdn hkIeqs/MSkvA4XC4UGcfY76DP/CpWXkG4nA4XEJSal5139TYFAAAUIa7uyrSEuLjcDgczg+J kOM7flrSAkNdwMnpeVXEkXVZxb7iyBArlUdy5hG0pYMLcA3Q5r198wjbj/e5lWzDGBp/uPXW 5RbgcTgfCx/VOz/yW1l7YnDJuXlVpBEwMwuGWkszsebiog8vs983xETGZNf2do0AAMYnxogl ifHJ7spiNzkvX5NEJCTkFhQkJ1upPuX+5ZqkYVxSDL66ZWBsAvQ2Z7hb3vzyz3/4nyv6NLhP zWSgHkJHTdWMnknq3eDibyB7S84HV9e1s1PQQ22kikh/d8Ubf7kivS6om5qCr2idmmbYnKEA QEyyEdZS1tWwooe0QalLPjp1+syhby6phnvjmYV8SUnhhlLiXGJSLrhoLA6Hw/mZaWgIPnoo buRdNdG1vja6+0gRljy3ZNRdbJhGY2OqJikmZmQc0zpBmemtzc33VDGS5z8r4xmRXNUyODYB yMNdDUVRXk5CBx4p2RoGlZQQWQh7v2O4VRURaC8VzgP81rbBOVVt/VWEQGe+766ph7vE1xK7 akqxbnpXH2pGRsbX9nWN9BLzQp1l+Z4o23gGhDN20VpdUFLdzDqGtrFQ52muIPMLl44Lo/Kn n7O/gSyHrG98PW1SyD2gxFiIU1RCzcqb0Z2riYW2Fj8CWz05NQ4AAL3EPB9nOU5ujSjac9Ev 2E9HjOPRle//cf6htJxbfn7TCJVB9xZgAixUGbVq/ZwtdAUuC948fEaJVpaHaiX+HtrKonKG aByDwGyIRwBK6cljWdvkhuqdLZ3BvvaKXOr3Pg5np/TLs8ccvxitTzcuo7S0ib7/VIczlVV6 xC3tgothyE6Qr4HYTUIr4McAACAASURBVFmHhIaaHR7cnxzq7ChPi4/D4dwURJ7JcktvLMrk vOoapkdPQ3mqnRHP02dG0X6h9FaROJyDkaSwvKEPQ37aC0ItkfLSz/RcsFh6L4ND/VEqjx9x 6wTHUiny5CBoDLRUElNQN0czTaGLk7miJLeCadpU+xAAAIz1tjXmricHZ6ek+uzxvkfGtDnK yClt6mZk0ACA0Q6Qoct3X+Tm6TNcYuJKsa1TWx5J7fEWFqoK0hpoJoFZPycfbakbv5gG1raT AABgeKA9PVDhpqKehx1DD61U+QSufn/q4vULct4xqdVtQ+PrOweUHkCylTqzj+1PXx24o6Ad 28qqouCOrD0vWEdHjPeBjOt6Jn1MzVUF7z6RkfGrI/aQwWBLaznGy1Xl5718ho6hyTWkznEw PTEyVJtO8FUSEpHllXVJzahqn5mdBAD05GUHIeUExJTtsEER9NFgcDiECh+fpmUcrhYAyhgg FWWlmSsKSQjxGXvjC2sGZ8nTYLClojzM1FXl/l4+O6ew/BrSwHavCH0s+4+B+yuv4YvO+uK8 HAKBgHX3MxHeu1cY6RuBJRAI2aXF9YMvaBTjzfPxseYCAoFACFB99lj48TNUAE0bLa+2s2tr yZX32+sZ2BtpKyCjbeHiRhdZc9LSlL175vTFE4cFDQlFFWNzz99s74nZBvvbvCWP7T3+nTg6 qrx7vKwZI8a+d993Z/Q8kptoZ6jXIBypirZDq6nIbQyCQCAQ4iJDLCQ5hM1ic4hkCCF8s7A2 WldWQBURDQp2V7n6P9dUPUOCCQQCgZBTWFY/RvvTdIHyvLuK5sbVSl3i/hEBQwKBqqZaUN3a sd3Zw022trY2N1BXX5pNwLr5IIT37RMx9Y/EEggEAiEzr6S488Xca5qc5+vp1Z5IGxWEpUsg o/CgD1rDyATtsFE1A1AGm6oIhHR8mgXvFTkthNlG66qWkennEL5ZeD5aiy+w5RWW0xa3Si5p GAQrywTds3LK2hqB1eUdgyvLdd68QsbmtoHVrR1TcG11pT5ES1tDQ8vSjzGNMf6OVpoy3GpR JSOzLyGEcGysM9aGi0fPJiKQOgZCYjrew1Ra9NHJfRc5ngg6FGXUj72kHUdfBn0zeBnOH/7x 18++vyLtgGnckp0Pt+muN1F8p59qaTPL/oY5GhgYm+szuX4x1V8QrsItoWnjGkRXwU0nEPwd 9JVkFMz0MY1ra6tzA3V1CeYGGvIcQg4ZmQ29LxcXIJynDHZnB6QaXP9ZwtI0oKChe3IewrWV 5ZF0aytNDVWEcyBTbPdAA6XbvPbxQ5R+ckdHrrenmeT3N4yDMAUtI9M9VdExere+F/UKSqrv Jr9oIoT5SHOIemUk1Y+Ta5ISHY14xQw8CYRkap79HCzl7z2+cYTtR25p0/CMtuEdvYrCaKPl EWHaZ48JCl8+yGPqU1jL7Gi0LjESxXdPwSscux45KsRS8+njByfZjt2TkXTMqOxcv2CR3NFB FRFNTyP4KQk+FOaWNKcNv6Cue4KqDLy2ujLXX1tbkk0gEAiJYSmuwpfOCCuhPMMJBAIhKyOz pIW8QBWCfUXp7QhXEVFBOfhErLvBpxEc1VWFrx47c+3EbW3vzNJ6WuMPt/nJ/q5KAiEthYDm EpDVlUKHE7LyM0u7yQtLb+Di7AipKtbDWeh7dg4lfYfQwpr2zilIhYP9xIqSaGd3LZ7vP+FQ 8gtPLCsrKYnxc1C6/gmHul94aF5dY8/kPHy1vNSepvrz9b1/PvSIAe5DOFqbFo2W5NP1io5L 3lgS+FSCg7qKjqNNQv3YO7vMypbmloerivOsFO9wC6wL6mYQCNWtozPMR+4nSfkebup8QsaE 6HhqyFCMv4H4jUdX9v/tsqChYQSzkO9zUjfeTvnyNVGrcO9YAoFASMD4u8pyPuaVRcfX1q9v Va1AWJvqrK4vr6fvyri+Q8P89CU5BZS8q2oH5uYn+rsyfZP0b54XtzEPKiL2Uubh8urybH9N Qbwpn6qC7DOn4qzG8fktarTvGO7McFVSnuUTPlk9Wbu0MuLwzOLLNLUj0iqGuiG1VV0Dr+cr 3H7hMbZyDKkldU29evOqLdVcTk0DiXKLYOxiiIu5vrKUsHP5GLXg92RZbYTuqUPilqHYDfHd tBSCg5qSjpNtIsOkDODCzNTu3tXyJhBS6C2xoUloWW71AGzdwDSEEC6+edWaYvZYU8fezHPd F4Fgb6ok9ejUTxfOnrltkpVYOzH58g2EcJHc2RamKqhs5kxT8k1LSbJX5VZ6fIZTnKEsD4Rw uKo5zITnvhwyCkeXtSXgUwh+CB0FNQP35NwdLp3lt8OthXn5BAKBQIjyttG98bc7GsFO1C+F 3JIcIl0ieKK3Mgxx+rC4VRiDNHEagWBvoqhjZp+8U+66tvJ2rq+6ujibEOXgjJQ6fBsRHpVA dZpVUF7W/fLVG3qtJPBqLstXgUdN28WO6Ys6xNtGV0NBTy9uYGp94xqQOzJDVPieaTp4heIY Oulrqy0vpWyNimledzlRkh1ooiqlou9NSGCYwuQElCqXgLFvBbUG0+rym4mWwnJqdiK9YnVu st/RRK5rsudm5RAHFpc2/+JpjwpEKp8/eV/49hFu3/KKoc07FqA1K8NZlU9Q3yE2YSORqckE exUFSWNUZFELhBCuQDhUEqhnqW9kuPHDiBDsZKrFffb68a8P8FpYhZY0909t/L6cSYtAPD7+ h7/8if0Ct3tF7Y4VuTd3c6w9MVDp6p1nts5+cQQCgRAfmuAkw/2QR9wqOZU4A1+/eDNUUZCL luGSkVdwiKlo7nkJ367ChbG2tkxXR4T0MU7TyJiSdjJ4CSFcHJtvDkZKimiYentsrFoCgeDp ZKKsIod2q4AvXkM409vTEOHpqHH7uLRdZHpJ39TUa/j6BWWoPC4X/ZBLxkDRMb2ieeQlhKvb dv8/3P7VcL8rM8td+iIb27db9c5OS2t6ZzbTGjZjtDQfH93a6tsfjl00IGQ37PzccEdJh7fA iUP71h39cPmnJ1aEPoyJyO0rbEcvP9V2qgGjWw/Qb2NNGV4a0px3TqsndA+RAciOspR4cJKT 9k8my7YVkrjCNJajT7R1I5o3WlRHJRg/eIcaHNtVKZuNIr/ZtmixK+9q+dAkNXaH9RSG6jJS 9S4eOcBiWo491WHqJACgo7jdS+D4wX30Nt8dPHHJMCOPSIe94wDE2QhwsOriqaNnNfz7R7oA qIpEG92nz76sjl92TlGclwDbj3vZ2H4xtYsl1BFc9C6yff8N2y+meFwtAABQhrqq7B88vHiA yeUvpg64TQOuKooz4mdj20uPek9CIbAtVOYYx09sbNdkJDaO+4G2RGuLJ9/8z9+++1TQL23z oeIdWlUEzvDe5hF/f4xNyJ/AyjOpEOfJz/bDXsa254UDB6hth2rxyboXDu7/ho2NjVEUN8ua /9nP1LwfYrtk7JvftH6ecawX4BT5bx5nin5GTj8wtwWAyUFSld29BxeoqTt1/IJW4MBoXoiK ysMjbD9ePc3rmj1MTrDiffYz249XeXlda4fJ00Tqp3R7ZObo7Z7mJH6B7cA3bMJmGVV1W4f0 gUYMcVV5ePL0gwtaiUNjWzfqiHgXZXEGEdHrcs7mfmlJOhd+3PcN2yMz5/g6QB2R7d37579n scrYfjx8hg+RM9I8AgAAgzVpidRrWdixa3yGbrWAVk97S+Mfr515Yp6TZy5x99wRtmPX+I0Y G3+gZVpyi1zeFJaH3yimFkxOg8pg5bsPGNNsnpVYDwBo625ylz+4/xjt/w8cOCAiInLsGO0/ vjvMdhnhX9TSAwBoy2904zu4/zvatRtWEYbUu7spN9fOCbhvfUVge6sIi9Ld5OvMyZ91g0fG t7zukhGGFGZoeobHMMQZE+XGx7bv283quwAAUB7K5Pk4ryACW7u5UscEAJVBipz3DzN1gNc4 FEsTJMiw4BK6xMbGxsa29yjbZWRgSUsv6KhKttc6z7aXKs56U0HefXPFrndZeaixDictzllF 49D87JwIV162fd+ysT22dEvKoIri7mVne2yZm9QAAAAjHQ0xst9fZf7iOqsYFJrP8LpBY6Cj wv2TbMx28MZ5QY8CWhl9AACY6AOV1gp3zh7e1PI4nxAyto4pOa2kOmfZ7/fSwh48dkHIpIAc ZPBE8BLbwRtCQp51ZNrrQQOVSTjN8/tpSr4Hbwhxo+Jz9U9s1NynW0dKgs2z82xs7Buxz56+ ph86PrlVBXbbXGZjtHnZ2FjegWwcSkqedLXhxmQ72WcnNmfn+CUR08LJXZyoHqhIwGowaPMy JpLfxDR2U9GqgR4i1urm3tP7mVo+sS5MadzsuSUrzImHjdHxOzRyCUH6AneY/P3E8QzlWbex R7jVFWN2nqh4pW6+F8gAVATIcnAeZvkpzUoDw7SYIx/kuPzMq5gyPcbsyl/6JifDOjurEuZo rm8lcoJt33G2n1FhlSTqmGYHmikBjy/+8OWf9j/hN42r37TlsEsrzQzR5NlYZj9xiJp719Pe 2ygNCNGkD+GsACoqrg2Qu+orLK7dPEWdpHPnbhmFT03TtuyaWysdJL/9hmE0+9jYflbBVBdT xzDYCqIl712kfn7op5/FzEqmO8ZBaYCOxm3aFedUUFHF7e/o7se2/xi4/2oCttgrcJw5ulXv 7Mi9m3KYFgipx5hniPhk3UssxeBOizs4ZW1bepmVFVoYCDL4vKTrgA+LidLjZz/Azn5DN7lr 56cRZ8idifY32E+LeUYVD0DYP9DsIfPNt0cFqP9ksv6iSA9+poEcOMNx06F1Y6MCDKwmyTy4 zCI37OzsR39+KJcCh56v+yK68bNsxs7OflnIyKpoZ8NYW1vtCZORvXdkq7cDZ2/fdGjtmWRg C2ursACtL8A0O6clnFxzGHlPY2G4DqsufsvOLmAYW9YE4Ww/MVGG/SI15tEHtxXDW1aWM9D3 +C+ys18WfmSVubpMDJO5fvcI+2VhhE3xut/RDHtb0VPMAxZ+Qv943WZXlhPNOC9cpEf9bq+g N8nDXFfnLjv7sat75VPoddXnh4lVhgcPf/33v9zQMtxae3hHNtv3Jl6a88Jh9k1239CElefV 5TcFZpy8F5naPjCKo7ZdXXnbHSotxUlN0PG9+xW9SSNDEPYVhLnw0vMupcx4nrEhJEybk8nd 0YecKpGtEL6GcIRga/PsFG0WBI3iygsaknBaF9m/+Y79soFrZktZXogLL/s33+27bIDPbAHT 9Qk4LYbOXRHlMo1ZqreRvHLiCPsDUVRM8dYhfaBN17fitK5/t2+/oE9CxdYDqtMjLbE219lP 0EREj1/nUUhaKnKTlLxzmP2KKI9dCbXdSLqNlQjzYthYZpel3LKpKHB1eak7WELyzpZ5YWdn Z/9h735OQ8JAK/2k/qbG3+5lv2zoFmzvYSlygf2HfQfuMjb+QOvNDXLm3RT2/IG7LoSBaQCH 6+ItNS8wpFnM3L4UQrgMYV6QOvf/Y++945rO8v3/3+Puvd97d3b37uzs7uCM03YcdayjY69Y oxKqoFIUUSygAgqCQaSE3hWQIk16R6RIkd6r9DQSIAnp5dA7yef3RwpJwFF01nY/z//M5+S8 3+d9zvlgXp/zeb8PyHwJgUAcOCDzwUZD0wfFJAiCZqeg57bX1DZLvisTSnx98jmlX1bI9PLV N0rbrP0Lu5Z8PJWLH0s6t1eur+VKSqfupNd1KDbtwdd7nVNSkjRd/euRa54tY8mWe1U3K1bf hSAI4uDkev5hyw9HfPPIvEHFbimNyQ7XZGKlpLR6C+KGbxfEn4IgCOopDPNUlwbn/LXAkl5o dHq8IUx3y37RfK7d9+NV2cK2vwUHV5t4VmnjjyI7KogbCW0TIzl3dqtuVlLaaaDlmS8qirv/ J6WdBk6ekrA3hlw1VZab6tUqN24kyLxuwGlojb+2S0npW9lGX32rtN0moFicRl8y3Kwkex25 4SopKf1r649H/QoGgExwZiCoMOQqUmL2KyWl7UYBxWHRIe5qSl99++N2m4JijOSo/tQYPvT0 GUklX9HVcIcLcjn3RYz2j9Q5nv51tcy2+UZJ6fTdrIaFVWBfBXt8KMFm5/pNSouxTnnVtZw+ cUohTl9zjOMupdXfyLb4Wklp+4Wg0jLGK8wsZG5yBBdySqY2r0wgt504JqmRK2EWgnBP7E+f XCvXctc5V+9qxZ6nR0Gh9fbjv8i1XKxGLr670s1ASelfMpa//+nEnSI6bui3upJG58efr4dT uQseppDr4u+abH7ZVQiCIIjVBeIMtq79QSaQ3yttRz0sw8m/MECujbU12Tzf6mfVm5fcU6rt d/6y8hulXy7eDJv/38xsuZuLzpo//O/qrxH3C+mDL0uktRRYI7zY21vXSkb/rx9WqdgWs/Ci rlmdvFj9X9eIhvDzDlXL+xhoaBoiZ9raaokm6VslpTP2eS3d4t6mICg/6MKxfXIx/EXtVniK dAz1Qfcv75Osqx3GIRUVTIjVWRajryS2s0ZN1TIFA0FLPuzxsfG+xX0ukznQS8DMFxKcB9/b L5OehkPv7yfiFrbC4nAEMvNN8hpzWdwBEh4nsYwl4IgUJo9O7u0hYHAEYj+V/TqpWhXgMAf6 e3ukRXGZdEov8SU1cplUUi9BvrAdsV+cVkUEm84gE19SDQ5D6KVSWfN9URT6koFIZtKX+GID j8NkkAk47CLTouikJJI43HxjLA5PIDNl0gjwAWBQST2LuYjH4ftpPB4XADadMj9cfF8/jcli MQZIGBwWgyFSqHQmmzlAJmCwWAyRwmSwAQCAz+OyqUQiQd5PIoXKUBgwm8Ugk2SWGb6nt4/G ofXhenAYDKGvdz6UoDrc6vq2ZX9bfsaxBd/JfosykUA0gz2KI8biMCQac7GeuSzGAAkjG3Us Dk+i8URteWwmo186KfNFcZkUyULC4jAE8gCLI+6axwWMPlKP/K7B95FpLI44dD1EPFY8C4R+ Go/HovX1EXEYHAFPGmDy+AwKqZeAwRFIpAE2j8/niK7KxnlggEntxWOwWAyJwmQv+VmYFA5t oI+IxxMJ/QzeIruOw5QvIkroo1JoTEY/HofFYogUKoMDJCPqwS+yaDEYHA5PIrN4oiXJY0u+ u1hLAok8wAbS9BKKjXEEPJHCYlF6e/C4BY1fk/kpmzdLIpHpbMDnAzatr0c+zEwGB0gqM2Ol V7BYbG9v73ypZiwOQyDTRLPPZXEGSDgsVvLdedg0suKSxBHwpAEWj7/keyibRu9X6AuPJ/TT ePwFi5tJI5NkmuJJZBqVThetdoXqu4v0LA6OgnTIB4BN6+uRX+B4EpkmvT8xKUSSzNagsThc hdK1ioVtf3u45Hmn8H1kGovJEg8BQ6QMMJjSnokUlijsPC6H3oclKG5B+fFyaNS+HjxGHtGk 8GUmhc8DbIq4BvKClcORCw6Hy6H2YaVLBYcjkMgsPo1MJIm3M4cvWbIKtWpxBBKmrUGuoK4U LoNB7ZX3E48nkGn8pa8cwGbS+0mL/t1XnBTFAsKSEfVSWPw3SP/OYzPosrV55QJJpijsFsDj cuiUHixe8S8MS7EhABwmjSp/935JjVyFvYDBYHA9vZQBzvxtZGFXstEh9g0wX7oXFr0qjTqN 1q9omdArv8xEXfXKbSt8H41KIVNIeAwWhyFQaGyuaPky8E01d9at/erHPZfvh9UzOL+PuM9m 0vpJLwuO3BDwJAqdwQV8LodNIUju/Hh8D5k+PyIOh03tnd8LGHEJaDqbJWrB4wB6b494i86v KzatX3azU+hvUzH6rfhoxH3hHDQ9zGczGQvrnTE4bP7YtOS01Nz0xPgga/Fyfrzh4Yk3Kuc3 OTTIlemTNTg8MTY2Nsil0+l09uD4zPTcq/uQZ25uZnyYTWfyRsYmZyFodnZ6hE+nM7gjYwsO h85Ojo1wFUu8sYenZ+aE4haCWeE4n8NaJDZ0Op3B4vDHoVmBuK9pxb5khsUdHFriu/JCoXBm jM9nL2ZawUkIgoRCxUjS6Uze8PzpfgiCoOnJMfASF7mD41PTECSYnR7n08XDFc2+UDgxxOay 6HQWjzM0IRROj/HZbAadxRscloxodmJ4mMeUHzCPM6wwYIFQOD7EZsm6yB2ZGRkaBGw6ncGi 8ydmxKGEeISGpJP/9d1f9xgE5laOvd3PecGscJzPXjiDnMGhxXoWCoWTovHKtR0XtRUKhTOj fElVyfmiuHILicnjj8gstenRMcCW647BYYOxGQgSKoaOOzg+NTk9Pg5YdDqdzhocmZiemhwV 9cwanJiYFsxJr0rjPDQmnB7msZgMOoc3NPbmGRnmpmdEXXNHxhepJj03Oz0+zKJLfWWyufxx 4eQIj8dm0Fk87rBYj5udGB5SWAyy7o5MiJakUCiUq88pHyA6nT04MTsjOaW5SGPW4Mjo8MgQ j7Wg8WsyOzk6rLAZGCw6e2Ridk4AzU6PD8mHeWh4ChJVZh4FcpWZORwOmy3zAZMPRLMvFEKT Q4DLknxXJpQzU+M8uuINlzU4Mjmz9LvdjGCct+DmLd7O8szMTA3z6NIysAwWBwxPC8YH2Rym YvXdRXpmsBicEdn6s9JATsnHStTzyAwkuj/NyMZZHBz50rWKhW1/e7hTY9LQMTgcMDYtFEwM sjhMOp3F4w5PSHuWDfv0KFiwBYFCWqTpMbDI37aFkzI7MT7EVWwpDo5AZgyipcKRMcvij0yO jomiwWANTkxKlqxirVo6gzU4gY23WETcF8wKpoZ4LIb8fPOGJqZ+I437y2IpEIwNspiL71W5 SVEsICw7osklL1nReLmL7n3ZGrkykZyZGOJxFf/CDCtsKwiChALBpGgxyLBYjVyFvUCn0xl0 Bmdwcm7+nrNYV9LoMBhgdHZuwdBnp8aGAPNlV0WxnBGM8VgKG5Y1OKq492enxgaBjHUGd5A/ PD41xGIy6HQmf1DmVRdysoXZodXfbjFAVY6wJgS/x9n2OcGc7NpgMBicIWlw5mbm5ofAYHEG R2YggRCaHR8anJ8k3tDEtCTqQgiaGOFz5Lcgkzs4Oi4dw9TICF96ncUfnZyag+ZmJuc3O5PL GRwX/dH8tHnf4j4MzIdFTaL9KeTPmzcZJ9ZSmMxXt4eBgYH5ZCAQWiKt1q4x9MzNbIPvfzC/ AYX4Is1n//9+t83QKrQY+77S1nzqfDTiPgzMhwW9ryXE5Kv/WHPCM6S0d8FJYRgYGJhPmFkI aky8aXDjiotX/VumWIH5tJmDIPIze3W1vYd2m8YShqDpTz5tzacOLO7DwMjQHux2TmXnznM3 8wlU9tLPhcLAwMB8RPR39BSG2tvdRYmxuH37yvnzbpFFmM63qJEL8+lDf9Ge66T+z7/vvR4Z W7n0zEwwrwcs7sPAvAm8hvYEkzX/sVb/UXUNffzV7WFgYGA+XuZmIHxeRtR9tBgnNPqaubmz b0x1y1vUyIX59BFMQuwszzMHj6mZ3crofXV7mA8eWNyHgZGhOiLkrp3pvZjnACwxlREMDAzM xwa+pjPWUk3lOEKMhvbZO0H1LIJijRgYGHkoLd15vhePG3lntTaS37czny6wuA8D8ybQWnBJ Lmrqbml9rKXnc4aBgYH5qJidghqCvazOI8WoIZHGLmlNsLIP8wrmJiFyZqitrfODrOIl1+uA +RCBxX0YGBgYGBgYGBiYDwtY3IeBgYGBgYGBgYGBeSWwuA8DAwMDAwMDAwPzYQGL+zAwMDAw MDAwMDAwrwQW92FgYGBgYGBgYGA+LGBxHwYGBgYGBgYGBgbmlcDiPgwMDAwMDAwMDMyHBSzu w8DAwMDAwMDAwMC8Eljch4GBgYGBgYGBgfmwgMV9GBgYGBgYGBgYGJhXAov7MDAwMDAwMDAw MB8WsLgPAwMDAwMDAwMDA/NKYHEfBgYGBgYGBgYG5sMCFvdhYGBgYGBgYGBgYF4JLO7DwMDA wMDAwMDAfFjA4j4MDAwMDAwMDAwMzCuBxX2YdwyDQW3OD3IKTiopbae+b2dgYD4VOHSAz0sI ePg4o6K273078w7BVWamRQX5pDWzOLz37ctLIJXnx0WEhT953gO4/PftzCcPHUeqS/Oz80mu wHbR3rczMDBvByzuw3yoCCGIiytLyUhMT2/mvm9nYGA+IQYx7c/Tox89qWBCY7Pv25l3xSi7 vzXFzS+lrpM8+L59eQmjFNqL3BCP8ALcIGvifTvzySOYgdh1hfFxyU9rW3nv2xkYmI+Hj0Dc 53GYlJaCwuy05JyykhbS+3YH5i3p68em3Nv2+a6zXr7ZuEWu89iA0lJV8DQjOTk5OTk1I6u4 g0VmLNYTm8og1Oanp6YlJycnJz95VlqNAx+svgcjD7G7oSQ/OS39SVE9iUPjvG93PkDYFDq+ 5lmaZHkXlNfgAfc3ljeTBCpRupt3qpsERrb9vq5wAMA2FuVkJ2fmFte3Ut+tQk1srCvOTk7P zXre2svlLVwp5UGmxsjtKy8lUxkf6jJqemB/CnHgyA23OsCGb1BvDY3U/aIoOSUlOauys7uP pXiZVNEcfWntf606H1hWSHgf/r1XWGQcpvppSkpycmFTO2Hgfbvz/uipr3n+NDk9L7u0vZ/P 575vd96YT0zcn2DicY3PcwtKcptpg2PT79sdmLdBCEHYTDvNMyd0dEJwizcZZ9CwDSW5Yio7 qIurdkIhNNKHa6p8LmqXl1dHHOJ+Ugv/E2Z0lE9oys0tyC1pIjBhxXMRhAJopBfTWFEkWt3P 8utJI7zx3/xKX2qM1ak9mw0cWyHO5O/rDZ/Z21qbm5+XX9nBGBt6l/fgUSYPX5ubm5db2tHD Gl64Ulhd5VGa/71M0zexsv8durUUWFWNjy6v+9OvZk/6Ovjv25mPH8HsDLOjtLo4t7C6rY26 4I4/OwF1+VgcOaRm6B3V8z78e68I5mZGSHX15QW5ZU31hP/Dj89H6GxsTW5efm5pF4kz8jvf Dj9RPgRxn8vjPUGauwAAIABJREFU0ckkKoPFWfQHGJtKrPc8fmKz0p83nlS5l/uuvYP5nSGT 8VkeiJUqpoHBBYtJL2wyqHO/htiy6ssv//63v/5z2XKEP7ECu2hPTfisW0dXfPf9l19+8b+f /Wu7qmE8oDD/ze7DvB4sKplGozNeqqnkP7Y7c+BvXy//fv/1XMoLyrt07SOhv7473eLA98u/ +/LLL/7y2YpdWhcSAZ398vasPlDrcuXQiXO3IxI6f19XqAAkOapu2/in5b8cve5aC5jvUirL c7Q5ufGvy375/qBrPo218GWf6kibm/rHdt7KHGC+RNznsrh0MpHKZv/Ws5F/Jy/CPI1Pa+qg 7jfB4v7vQGdBtJfq37/8yx++1wsKXajf99W0Jt7au3yXWXh1KfF9+Pde6atOTTDd+PXf/ue/ 9qG8Upvetzu/O2wWndyLeyk9vWQKE/D5AGTbWmhu+Hz51jUnvEo4vI/3FY6PTdyfGh8ZGx2Z fNlh04F8Lw/dn//+/Zo/aCY2E+HDeB81QgjqeeZhdFX/0qXHxMWbDORluupuUVJSUlL622f/ ucMkKqxp0Z4EUE+U+/lD65WUvvzHF5//8Q+HPdpKSP9O32Fem9nJifHhwZEZaE646HUiscnn nNKybz/76aRrVi71HXv3MSCYgQjhaH3ldUpK//z7F3/7yx+P+mAq+n7zK5TsVKfLakeu+XRB vN9ZzWoqDDNB/n3Z53/ZbJLZ2/YuFeqewlp35Jf/+Pz/rTBxz20fWHCdg6tNMvpuo1FoZv1L lpFQCE0OD49OjE7N/Zt9fQmchtZ4K+Ufj9rlUzAf6tsFHxHT40OF1tuPrf7sm/1GRgv1+7lJ CBdif1rnnFlwUu/78O+9MjsxjAvW1tm+7M8btI46lr5vd3535gSC8SE2i818CSwWf2xueg6C cDllLie+/ErpjyvN/Iq66e/b74+CD0Hcx/UTo6+pOCcUtuAXu8zncdlUIrHY087O6Tws7n/0 8HhcBpWII/YP0BbVCPk8wKb2Ewk4DKY0KcBZbblG0EvEfR6byyATcVgsBvPE67LNeVjc/4DI dza5HxiW0PGy60w6pbcyIdxDe79VASzuLwaPzWX092CxWAwmw83o9oVXift8HmBT+3qIvWQa /Xc+ws4DgE4hPo+0vHBN952L+0wKuTYixO7ajoOuBYuJ+2waub+XSCAzePyXvFDQ9bwj8vpB p7KKzvd0kJlDo/b1kkjkATZ4mY8wrw+HSSc25GdeW3XY4tEi4j6PzaGTe7CEfhqb9fEe2H5T eGwGvaMM64vYpOf+KYr7lc8izdSXLftq2eJsVrt25yng8gBgkvtJGVEBaP0TXqWwuP/uKIv1 CfX3LnjZMbvZieHhnoLyeNQKzcROWNz/uBFC0MzEMB/w+PyxmcWbzE6MD/NYdPoAlRJ/ee01 9MvEfSE0MzbMZzPp9K6qnKATfzgbBIv7Hwqk4vREOxOfrpcdIZ+dmR7hkPvjLx5ziYTF/cUQ CqGZ0SEem0mnd5RnBiD/aBD8KnF/dmJ8iM/lgJc/U3ljpidHe1rzg83XbUblvFtxf2ZyivGC lG1+cB8qYDFxf25mapxPZ/JHx6de8nR4dhJ6bosOTgsqYfybfX0Jc1PTY4NsBmdoYnZG8H5c +JQQCgSTg6yWsEvWVrcWEffFG4fLA6Pj/2eSU0kRCgUzo1xuzj3b21aforjPGuHH3d66btNX i/P9ynV6kbQWOgTNTEwOd+Oxgfr77ONgcf/1+BDE/e5eQrDBTpvInMZFJVwxLSFebu4XYHH/ /xJdRbEPdJZrvUzcl6Eq7JbTJVjc/4B4aqPn6nk/ovW32nQUpD3U338bFvdfRcXD6w5XXiXu /9tpSnO8Zqn/zsV9AEBXapKn5Z6XiPuvpj2vNejcBqui4ja4yMcnAh3fXGG99rhl+CLiPkxf O4hQ33bW81MU90uyIu1PbTnvEp8QnZiY6GJ85fSJ70/YxMUnJCYmBlpqm1+/ZpoqTV9WkhXj bQSL+++UglAHH7T9E+xvNOE2dec5r9ZM7ILF/f8zCOZmn9385abrS8R9Gbj4+nitP5wPhsX9 DwV8blzEjTMOrdBvpNyZm57KM1f1egyL+6+A3V0Zq/3Hc6GvEvf/vbD6mhLubtx8N/fdivsQ BI30jtXePX7gbuBi4v6rmZmAckwtvWI9nr3Jt2E+THqTLJzuWi0i7sNAEFTl5WF/51MU9+nD /OhL2wzvooMeZ2dnP74fb773H/uvo7yjsrOzk0M9vAzWn4mg1VEljUHspQOOCbC4/3q8X3G/ vTY3OhB1/aa56sZv9mjoX7mBmifwSXOt7M92kbh/M4JaEu7ieA+FQqFQaK/glAICWHg6r/1Z RLSPTF8ot+CU0uret/CUgqGUPJLYRaFc76OjSkqjHFOLWurktIX22pzoQFnL6OCQ1BoCADI+ MpgDLflBaC97yVU2nduQGO7vgkKhHLxDggsIdBYPtOflyI7BLSaltK2ju7HkEUrqxXxjAAC+ pjFDzrLcVRFcJsDnJz/0QqNQDt4hIYUEOovXnhce5Y1CoRwcXUIyWumk1xXH2QA05D3y90Yt /K64ZK6nPQqFQrkGRCc3AiYHANBekx0VIB1Q7KsL6r4zcZ/R09qc6ulkfxcVlJVf/Ly1MNoT hborctQ5JCSthgCATBzJA/3FCc4OzigUyjcmuqCDy6DgnwUGetqjUCjXgMeS8UqiQWl+FiiO BgqFsnN09cpo6+xdxFEG4UVzqqfjvbuSZRbgGlPanuWfWd5Z3zPfrC03LNJbbnmHpJXXLKyh ymUA/LPEQE+02LATyiszKyk48WluukJrBoHclBrgeE/so4OP8/308id+4U+ryjuWdtiZ3FX3 PAzlYIfS27vh8NHjGqYybvrGxhTK5YvpKEh7qL/ndkFzTFhAkMhLe2dURHkrfoFRXFVdeoDs mB18wkKLCMw3r7HAAQBfmRAQKIkOCuUVl50cmfg0Ib22BwAeAKSKhIRANMot0Cu1iSG6y8i4 4R5XVtExAEA/tbcozsneGeUeml5RUF1bFIayt5NMTGBsapP0BoXrrE0LQ9ndRXnFlXUXFz5J kxmQb2xh0ctz6bxC3MdV1c735R76GwV1SRUF8YGusnH0i4tdxDATgLrsEB8vSbBRqIjs9vzQ txD3KS0Fz6LkLLsFxaU2LVYkozU7M9xrvt3D7KKnIQvEfTqtvyH3vr27vbivxQvqiroyNTBB /qK02/C8qSVqfkSROR09illbcJU1aQ9kgxMUlVYW7/O4itXzBof++zuIhWH2dqLt7Oy3SEFd JgB12cE+Xihnv/AneS+I1TH2PqIF6ejnEf68i8NdkFH+daAP9Nbn+t9zt0e9YrwAANBP7imM sbdDS9aPm1tUZWWUd1Lx8ybF5n3tVYWhKDvJ/cnRL+JhZlNVtN+zRmyXOD4cAHDlsf4BTrJT HRz/vKlLph9sRUbKA5Sds6d3Vhe2Ij39kadkD3rHL1YFV8Gu+8P4+Pzm0tsLxP3Wp6/qCtte lRKKsruL8k6oxJXkp6dIZ9s94Ul1V/8Cy2RCQcw9SXDcg32TKzmY7Fh/NyeUs19kVnEP4C35 VQxS87PYCJf56Lg8ysqql7fc10YoCLW7a4tCofwTSoq76QOkuhxfO7d7KBTKPzihuAUAqVk6 rqE2yUPUGIVCOfpFRmaUcsMXivvEprwYWbsLuwIAMPrxtY/tvJxQKJR/cGJJC3uAj8uJ8XNz QqFQ7sF+GS3cpQ/4d2Verx8AAJT4B9qZrjdN5XB5AIDOxDuB6FuK4v5R+9LurGBfV9GSdPTw j6rm9dIV+8WUpSbflw2Oi39Udgnx/b9q85GI+3zAqEpBo73Q51QPIA4q65qh5wmIzS2Szdoi FfcLU3JjA9BoNBrthkY/zO5g0xbkoeaTWqpiZPpCe/kFp5UyoOGXnBR/LYhFErtoNBqNjq3K SYmtLMp7Lpdahs+ni0Ykwc3PObiskzMi46MQgri48tREX5mrtOaW7DA0Go1GOz/I7sTQxyE+ iS47Bq9HwWlNDKEQWxQe+0D6qaQxBEHjPGFnSnjAvGW5q1KGcF2liQ/QaDTaOSCnC0Mf55Na KsV2ApLKMPih148IjdicLXFR9rvikrkJvmg0Gu3s7BJbzezlQxDE49EqU9BoT9GAwl9dUPed iftCgYDTmJwS5okOiI/MbxXQSpKDfD3FM+jvElLWzR2Vn8GexuyYMDQa7R3kktbFGpwcxJYW J/ii0WhnF9fYGlYfkG3MwZaKoyHCL6m8krBIoIWCOU5jcnKYp2QCXdCxNRXP0lvqKotlxsXr aap4LLe874dllDOg0YXLexDbWZwwv178kuMTM2pKk0PLGTzZ1kIBxGkoSQ6T+OiMDsjNe5JQ WFqQ0bK0rM2CudmegtDHD9BmBifVd6w/YIK2tpdY9w5yS+9mD82f5JeI+zGhecVZUi/D8wpe LJBixjiz7cmh9z2lQ3F2cQ3IxeAYv52E/rcZpHbI2EX7RSQm5daUhoaV4/lj4xA0Rm1vzXqA dnZFx9W29wOpGyH+Hmg02isiM7OFB0ECCCI0ZD0ORXvdf5RZNjDTlhPy+L64RxdX97haTr94 MYzNzrTlh/jfR/tFZFZX4ShtyWh/D0lsHkZndENDL8ml8wpxf4wz0yb2Co32evAbBXXHqPQX T4LQaFfpoH2C3TO6ucNTC5pS8fVPZFZZeGJRYelbiPvTg3TK86AA73nLLm4ecXXcRcppcPH9 ZTKWgxJjsksWiPsCCOJ0P0+I8xX3hY5frKCuqCtHe7T+tt1HtY6ctZLZNRFJz9sUs7aMsqdb kx/6SWbFJ9gtpbUuxa+gurPtDQ79z81AhGcZUaLV4O7qEZ63SEFdCq4u87HkanNZRmaoaH27 ogPyqntYw0s3C0ECCGJ3FyXE+aAVxrvY8pmDIHxdRlSIZFrQ6Pj8/JTM8pLYcsXmc9OT+Lyg KMnydnbzCHiGL8162lArW7oWkF8UPLkvazooJLYcA0HSRTbK6nuRhPb1QPun1tTWN/WWRkta +kctVgVXZDfSX+Kiu1d8PagIXSDuc3Cv6mp0evJFXqCvP9o/6mldNbb3RRLa1120A6Min7Yy IUh+38xCEL42PVIcHFcPdHx9d0fNi4LY+2h3N8/IZ/gh9pLrhYzyqc1FQWgvyVZwD4iKrGIN TchYnp2C8Hlpkf5oNNo3NP4JRjA6ze4qiIv1QaPRvh7eTxoGx6R/PwQzk+za2LhgD8mkeAbm E0iZ6AXi/iif0lQUhPZ0kc6LYlciKLVpGSFoNNrXwyerYXBsCHS15MfcFw+/AUNdwn8R/g3M 6/U0CILoL7jRp7/Vi8iso0IQNESoqrbfYfiYrijupyZnP4uRLsnIQmwnS7HfEQaxORHt4y4N jru7d1R+z8jvXbzkg+b9ivs1eeH3riOUDx5Yv/zzFRu37lFGzHM9sCSvXaZtS4iXrYXq8cuR ljqHkccPIRAIBEJT/+rN+4XlONaARPMSVd8NQZ01VJftDHH6yh2n6JIqHGC/wZlTCgZfGB1x a97uIeSp/SdNr+74k8691KgasWUAKF3Vwf63DbX2ylnWv4z2z6p6wWRLisIO0PrKos20z6lt 3bhN87COc8qz6GR7Q10dpDJC+bDqGeS1xHoKk1ET+chOb8+WVT/8738rrT2wU8vRO6W6pqko +fYhjf0rv/n8q29WbNx3/qZFTDuFwQW0rrZUf9+rWrsRiKNSy5r6Whb+j/NbCdJytBwaaIv2 Mjt3cteGPYcPb0elPI1L9jHTNVRXRhw6fOKIml5QfTV20dq1C2ECUBhhrX1s9ep/fbvt8Omb /pUUjFhJGRjoLY2+cVJ7y/JVq9ds173nWQRoLABAdU6o3TUE4ugh5V0r/7rGwHfxgroyvDNx f6CzosRHV+vAquVHr5pcswq9dVZmBs8YXHbwf1JUTWQPiCV7Yj8h0VVb49TedasP6R+7EVKR EuFzQ11XA4FA7Dp+2uic24tuGpcDAADkPmxxToSDmTpSQ9qfivoxY7RfYnkLVvbZxkBPa1Xu Iw+HiwjkcXHDQ8jTh05dd9L83sAtN6YWAAB4bAalOT/IWu+c+gHZRXbG5K5LTFk1XkYqZVMY 3SX5vmaXdKWWVRDHLl1Q23j04q0r4a3zlhk9PVUp8fYX1aWGEVrI42dNNb7bYRp4P/cVc6RA T/2zhNsIdRXE1hVfr/557cZ9Ml5edHKIrZNt3FGQ9ODkah1nR6MzZ04hEAgE4shxtV2nrLzi SlpwMsEZ6HyR7ON1RX55a53VtnwQW9hOfJMpZ7PoXc3PfJyMxXYRCAQCcczwotreoxc1r0bU AsAFAJPp6npp/6/7VdZeSOwfYAEAQOvTZ/6miMPKiF++Wm8U9CAPDwChFxvvrKV28Mf1qoY3 b7h63tTZfeKYyE1l1TOGF5wy44o6iRQmAK11eX43lQ9uXrbyjK2fhc3NK1rS6OzVMLpteb8g uwbPWSwv/CvE/RdZeX6mCMQRBGLXuq/XqJktWlCXAwC2Kdb5nrHMiBEIZY0LhjZBWc9bSRyu eHWzKXRcybM0OzOdk2qiVXbkBGLXqWs+dy/oaZ7VfiNxn9j4LOyehYGcZdUz5y+5ZGXW9vZL 6ilzWXRyU94zHzPTs2rzoTl5zebWBWvjs5vlxH0qBV8UfkVVXxWB2Lluw84jixfUrQwLsDFE 7Nu2b93yv/y4Y8e+w5Je1REIVFhtp6ziDIiNdTGuTpc1d0sa7de4oKKidvXIStVgat0bHBDH 13TFWampHEcg9v66csN+5MKCujQAnoVaGGmu27LvkPZ5jxBr3X0nVQ4jEIh9+1X2HL3kXNjW TX2D5U3tx+aHX0bqq0pGcuQEYtep674RifVdWDlZs5/UnZsRbKG/77iKKDYHVdUPallf2778 pLNbUqNMy57OuuJ4LwcL7d3Hj0m6PWmoZmhzbfvqm9FlovopbAYJU+7ldPGUjuxU7zl5wcY7 uKShjSqWwlsy7/sYbj2wbe1KPT/Pm5dMDNT2IRCIQ4cQGzep3YqMqCTIPJwaIDSXpz2Qtbtf VfeC4U1/V61v91wLkxP3K0L8rc8hEAcP7N32459/Ov9wYUHdluqnPub7D2xSWqlp7XXNwuSy pnihbdmqbuQUkdEmY5lBwDWlxT0019srDs5BVV2kkWX8fYODazb+sv6ogW1wYudv1rhWhA0A pqEgzOfmRX3Z+Ohdv+4Rn1tL4El1c1x1R4ylyolje9YuO2yEuhX6NDHEzuTEcTUEArHzhK6J s28blcvnAwD6O2sLIl3uGiFkJ0X36p3EG9tXnnSRFfd7GiKDbS/I2d2voXsR5ZZdUt/Hkyby GiC05TmoGJ7cs3nFYaS2ZWBpQpKHyVkdNQQCse+43onLvrUk7u+d9WtJLFHcj7Q/vUHHzfWK jo6aaH2f0FA7bZOYXNkvW2yY2l4W537tkuZ+2fBon79hE5xX0sUbeKMnbL8XH4m4T2cQU12Q yDPI7etXrlm1cosycp6LtkERLTJtuU3dWajVO2+H3Lpww+jkIXEr1SvOyZmNdKbMD+wJJr46 ycdaT7Yz5Em9C2YPcgu7BjlvEJjpMYjWXBVkKWMXqaxnbYj49fKlq1YF85YBraoswfrsXqT6 8XnLqmrmzo8Lq8gcifIkhCBqXbybg8GBg0eUl/18Nzg9JTfK0eXaKWXkcSRy38FzgfGVpEH6 i54UayRy77plf/rmx43rEeYmbnlEoaA2wtxWd8vmn77/+19/3KyqevZBeXXPMDQFhvGlpY5n T59SPzo/aFXVK84+SdVymhe7rjLW4QLiAHLzsg03QrwjczMeuNzWVUYikUjlg7oO8bHNr58T Gt+S52q2f+OyP/+0TVn/bnx1A0dmgHGud5Cbt6366qst6hYJva0MCIJodEKyCxJ5Gok8tOWn LccMXlpQV8I7FPfnqDnOzsb7Nh/R2Gbo1njfzFhXSxJGbVV1c5eYpyV4hkSYE0JQc+4D1I2j e/Yd3Pe/WmE5aU/Sfa2szqsikUeRqls1bIpyWgcnIAiCpgUCanfF4wCry+dVZSbGyPrOw9xq LEfGhamJISqm5GnkPcPLuvMTqKxnc1P3gPUdO5tCcbtxBrYi3tNK94Ds8tY2MLYIfPYcMzxf T1gohEb6sHnB/lYyllWNzmqqXDx3eL19K0GqMs5OCPiYxhjHO5d1JS1VkapXL53cffLy1TNh +CVFUjA73fTo2h0j5IFtmzb+8PXKfcgjJyTWdS9reVSS2fM7cG56Ms/8kCXq8nkry8sS24dO 37DwSauRDc4UGMQ8f25voK2jjpgfi5rqVVe/lNouyhtkMRdC0AgDm5vqN28XiVTVP6epf8Hw hw0OWUQ2D4IGsSXPvc6c2Pfzl6r3E8t6IQiChqjTJc6mhjrI3Wv3aF7Ve4SHoDkIasr2szm/ dY/yLhXzhKJ7JicNtURuHldVO6h353FQVmc3ZRCChmYmi8NMDdXXbkWeNr0VEmNvsE9HXRSd oxpndM87P0ssIw0sVjP3FeL+IGWyGG1qqINEHtr9y5adu19WUJfPan2a4SgzYiTyuIbuQSOX mKzGHuaQZHWLCvk+DnIwmV9lh05fvGVl7W9zZsXm29lLF/dHmbT6DN/rqqc15y2rqh/SuxMT WdhDlNFHx+kYzNOgYEvdfUikODTaF/VNrTN8zmzZcdtfTtynVEU62OkjkUf3H//1uz8hHyxS UJfa0BlnjVQ5gdz6/Y8///LztsMyQ7/pFFncJtt4hMlrzsq0N1DXFi+zYxq6yvq21/d9cdYh 8fGLJQ4ZgqDZKagxxMvqPBJ55OCeHT9/+avZ04UFdTH1mT4W+w9t+W6jvme0teVlE53DSCRS RUV163Ydi5DcqjfRUgUQRK6MsL+rLzPcg6eNLb1CqtoIQ9D0fOmBqbmZvs5SP+fL53REsVFR Re7XN7tw5IjxtYP2JbLRGebi6jLTvU3UzmlJdqGahqqJ+xUVpM0970iCuB2f9Czzwc1Lsovs iLaegbVbQVUzc1z0fB30txc6HD+79/stWhZXLRyCbkmme9cezbO2dpl4+rzIPjXG7+8sTPe5 JrV7TFX9iD4q3sFY/fwVMzlxn1LXFmONRKogkfs3/2sj8tLCgrpgcrTwobGB6potx06ZmHoH 3TPYd1LtBBKJVD6gqWJgF9pKH5Imd5odm+F21Bf72F8SB0dFVWO/PsrH/fot3SPrv9l2+NSt hw2c/tElTQ2fQSzJCbW/roqc3wo6htq3QxLLCAy+ZCPMTEAND91vGR7ZteHQ4cNnwjufZj3y NL94ThWJPKKqsdfAtoqEGZmBIGhyiNNXkxFuq3fxtKQ3dU1VU4+AW6fOG1+XFfdHGE3VKfbX VZEaUrvHNDWOGtsm5DwnsWVvF90Z7p6mRw7sPrRhua5XWXZasqezxTlVJPKEqsZWDduYYsx7 1buXKO7zoy9tP2937bKF+TlVJFK0Ns6Y+wU+xckWG57k9rfnhdsZ7NdSk/65QqprnTL1TM5s ZNDe6Anbx8hHlZbnwv7v/r5hxQmvHNIABQAA6itS7xl8v8c0GVffywMAAB6H2dueb6tsYBsa lC/7s74wzkn39F4tw4gBIp235LO+1RGJd3T/uc85m0gVpQ+hNOc/tdyy6vuvELZZiQ0AAMDn MTkD+QEX9W3uBj2WfSZRH5d2+/SKn8+7txK7FA+W5kS4Oen8onpB9dvvdlkFFL0gAHxTXhxa 5Vp0HwUHAAD4xmwPq+3fHPfqLOkSy2l8Vj+7xFp/t97Fe7FFAADAB4BNrwpwu2Vz7mZMAwDS 393Y8rRAvRXfaXgklXQpvtxQ9SjTW2fVOSOVr77dZxgQXEAA5CZ8ARphHF1UvSQxtyDKw83y UlAZB7D5gDXQ20fq7aUwOADwAWgMPOvi7osuUPwOqx9bfW+bhmXQhyPuAwAAqw9U2Z29or17 jZaprlc6AOJf9HUxKVbIH1YdupSMa+qTj2NzkKvDjT371Iy3rv72dEhuLQGAutLs4KtqPsX9 dCoAbMbz3PDLqj9s1gvplb6GQiN2JV9evV3jul1k+bxqwKpOdT2vsfvg5hvpfZJPyY3ZmRab vvviv/dYZsbUAsDjMHqa8+7s0bUNDyuSOckP8h/bnTqtfPpi9EAfky9eZH213clmv36udS+z qkH0yUAPSL6ktffn1WqWVnEyufAxGenoK1t/NH7YSxUXvcCUdtzXWvnD8o0Xg+UNLYHXS8sT 7X7oPz7/4h9H7ualNAEAAKsfU+e6f88pW8fH1SwAxMu74j7a3MbodnwjmH8Dprsk0V931dca 3ukVmKVn1u4jdSTYbvqrrn1WgiQ6ACQ5qe3etlpdU9ZQd3pamOOBC4kUWYGHigOPT+nei32Q N18lJMv61HXkz8pnL2r6NVLFdYRx9VkeZrtW//OEh9RJKq4jWnudPnLd3iuO1vN1b1uzfa6c 2ae8/kIklsxaKBe+XloeJgCVAbpIS9Qi4j6P28/of2iNuHrPO71E5nPsUy+Piyc2qKDTScx+ HgAAcHsqmiKNt329yzS0olg0+cxeUOty6eDabz77ev3hpYr7PAAY1KTb5pb3zvvLWa7LdL+l vOHX6xmFrf0cAADg0nua8m9u3X3Y9HZk8XxoHl0yVv7mf79c/81LCuqC8qBwhyuLi/siXjMt zxNLU/2LR8ximiSv6WCzPN311v2wfueZiIEFp9iXRFOqvamlwUJxXzqCe+b7v/5p29rtd0sq OwcAAJ2FUV5nVvzl+IOcWvzvUIKXSQS1zue27jh542HkC9kLZblhN0/+cPx2MaND9Gi2r7Yt +cb+b7/+VgV9P7NF2o5DT3xwHXl4xymdB00MyRg6C6K9VJf947MV+kFlBQQAuKy+F6UB2suu +D+X+SoAL0I9LmohNS1dSpkcqX7dltPifnT1Tz9/sdnU+nFpFwCAggEJhofWIQ08k/KlC4xZ GW935sz3hPJuAAAgAElEQVQJbZ0HTZI3MzA1aS7XNn7xt//5/77TDVwsLQ8J35xgvfZny/CF 4j4AAPR3NEVqrt77yxcbdK3vJomf7+TaHTyhYaDvms+RnGRnt8TH3Dmza9Npu1JWNw0AUa1a iy1KG376dqXR3dDC9kX6/i143F5Gv5/5vk3aFwMCyuY/rwy7dU3n0K+XIwlUrsL/ERr9te5c V997XG37xj160awWEgCVYakP0WcCmtlcPuDQC/yuXtA8uu92lvS1lY78KE/kF//88x/+c+8d sbjP4wJGf7zF/psOcnYBJjPV2ejArxpmTymdFIVV1phke8fswB5dw+3Llum5lL14AUD7s+QI szMOFWzM+8xxU/ksOchML7CSy6MBRXEfk+Ec4WNv/VRG3A+8oPyfX/71n7rOFa2tAADQi2+K cdz2l5MOBSkNHAAA4HMBm1rqqWN6x80htVvWUN4jU90NO9Uf9Df0vK9K3AB8NOK+lNdLy5N4 afUf/qT0i5lbdusABEHQIARlOh04ev1echpJIlfMjuPSHL3uWRpHy/6s7+tr9zdS+vtpdG0h bmbJRRV5RChRc/Mha4e0Zprks57oCxcOr9ymY+1UJv5kbhJXk+Bpq23s3gHNP2wAfYIMo6Ob T199VFgzqWC5h9j5SHOF2XWVlXuO6hp7F/RA40JBe/QFm+icylYIgqBxoaA9/Mw6w1uhgTXT 0q/NEVPjUFeVd9k+gaBBCIKguWlaTVOs7da9Hjl4plQ7EgoEpY5HNXRNzUJrFFMP83oECZqq qOsHtu85ccj40mMiJBRCPVEevtHeMa1LCU0vsTNGd73V0y4aSwDNTo2P8tlM7sjE7JwAglh1 iU+ddE6nQTLH2MWQM+08717/cMR9iVsZiSFXN+3VPPXlxahuar/oQz5pNv38wY07NBzSMony Z+PZdW1P7/x83Ozq9tV71G/bxrdBEH92JuOeoV9SXjsNggSzzBF2oNmOjfo3k+JldMSWqJvX 9FQP3M4AE9CcKAf3LI3cFHHzly9/PhOQUk2WDH+GEGmov2vZelUzm0IIEgqh2TFs8l33e9ZX Y2VfGCERm7yNli877dZU3CNZ3oJZCBOA0rh4zixyXqJriYgyP/j9poPKXp29UoVmlDzdYKu6 Sh8VU/ZC+t1iO3ONLauPXZU3tAReLy3PZJ75uoOr/7pB2861XPwhNcfpntnFA7dzJyBIIGpF rayNtt1x0Du/lyNdSnMzk8V2ykjdG1YR9UvPrC2AIEyajZqpocW9+eg0Fz26ofHD5m8Peuf2 ccWGRvunGu1ULkVllckf8q57EBPorvdo/skHLif6vuaqYyd37bMvKOgUfXtsZrIp3GD7nuOm luG1Uidr/S3vaa49elb3kE9XH1c0C1xqRxJ67zc/qrrElPYo3ieWkJanrybG9a7G4uL+9Fhp lr+Tqar7UwgakXw4Rmlrctm3VfmG69MXpBkIgiDh3PRkk6eNlsYpk8B46W6iZCc7aG384p9/ /uNmk4ylivvTkx1PinxMv7ua3cOYtzw93vBIb6vmBTevXNIUBEGQEIImsfHWVnqnDt1I6IIg 0Qg4jcnxJhu//PzPf1hh4rpoWh5W12is9sqzYYuI+yJeMy0PNqvc3eCPW11z+rmi50Wj5NYG 9K4tP3+LQGWmdC5pyIou9jbG39306928heK+aAQNUWo/bt/0xZYr/kGlDAiCZiaGi+5sOaBt bh3V/PvkjadkxdnoHdllYN8CcefXBnN8ONpkxV5zr/wi0asJc1MQPtThzL61u85qe1VJ281N t7cW3FH/csV+64JiSVHg6fGhQpudR1f968BF70gCBAkF0ORQsfdZR3tHma9CEKe+Jfbm/h+V zVKJ7RzJ4p4eg7JNzNR3fL3x1GGLpG7Ruf6G4AdGZ7Yfs0uagYZFRSNmqYTKIPOt3x+6m1+K FdkdmRypCzm1acey//l6r+FiaXlmIagrycLwrtVCcV9MtbeZyf6v1xw+fMy/mw6mIAjC5/mj DbZ/eSaphzkiuiXPAQLrmfmJtYdMA0rLGBAkqlUbckpbdcPX69Q0jaLaZd5FeE2mRwtT3PV1 dp26ngtJn3Kyusrjzv/w00nXxHLShPxfGGbFoxSbvQgTi20rftK6l5vWBUGsruE0E22f6jLc EDQ3PdCc90Dr658NH+U20SQmQMHtrUdXf/bZOo15cX96tDXV3euG9vVcaP4B8EjfcI2T9i/7 LnrlF/QpvPbF7KlOsd2AsLixbet2rfPu6dUQNDUyWHBbOyijrJy5xGH/nrBGBtMsT/pkVuCZ kKK4P9Jb3+ClYpbCahEHgz7MDbv07Vc/fX7YwCOzBoIgaBaCsJk2KtdM7B0KJbM3O9H/PDjs 7nnVBxjWkPQ/WqxhbozlryvPWKYntLysmsenxkcl7lvcUNP1ySZSB3gigZ7NanvW7Km9164w r5kCAACUFmKB01E935RnrQNy+hOLTmkozoyyuehV3D+w5Pze1RGJThe+0nvc1UcX/cbjcZhM MgGHxRLJTJHcxqYQ6r2O3vRKfVQyIHeujU1ndD2vT7pz3rm4UjGzeE6EjdbBn/btt82ubSMN sDhcwOUw6RRiP53H4wIAAJdUkxZ/deOXp0LTK8UyIpuCr3fZu0f7tk14BQsAANgA1Eeb3nT3 Ck/rp7NlXrHnshj9HfVP7xj6pFUqahxVjxLMDn7+nfKlqPrnHQM0JhfwOFwmhdhHZy3t1QZm Waibt7mJRwOgcUCBq47BCVUNyzjRM4Y8u7Nu7r6hzYrf+aDF/T17Vc65P6ygMqSRZNMZnYUV Mbd2nYsurJGPY3OQ6/m9m39VPR+Ka8bRmGwuAGwWk9ZHorJ4fB4AdbG2btc0zwXjO/t40rjy uBxGHy7e6ugtlKtPsaSrAidPVxfj+2X4fob0/CaPzaR0VmVZbLjs8yymFgByI/aZ04EzvhlF 7TQ5PZtJp9QVpkWirviWDjDE+mVfbXf6rV/XmQc8a8ZKDANGH6kHhyOSybJrFJOR7n1z5x7H p/10sugTLoszQMJhsfg+Gu1NS1K+prjvr/3NcfeGvBdMkTDL59HZ1FwvvevuAYnFAADAAqAu 8rKZu19UBllhedN7W2uyrA28M2ueL/kBRB+pI8V201qLoIJcSXQAYFBIBAKORJI1tARx/wAS qa7hkEkaYEsqu3LZDCqmtuy+9m50QqnISSruRbT25xuQ11CR5TKzwGFS+6pTIj0NVBxLBxZm Qnp7cZ+K70gy3m0X8jSrjSF7DpXLpFJrUqsCrpyLpTcQAQCg+3l6uPFRs6S2agJLPPniUr0x HkYntZcs7lMBSHI6b+fhn1UldwKWy2ZQMTVVAafORtU1NAMAQBeuI/zcthshT6pf0FjzoaH1 9WW7e1/Rfhfi/vXbWug86exzmVRqLx6HJ/TSeG/yytc8rxT3bxif2Lry/KMOIp3N4QEAOKym lkqPE7/YJJS1v9VjBRF8LmBTEq/vumbj4flc9kJZbti9M6suBpGZBPHfNjZHVMaZSBmQieeL sLOObn6OaSTSAIcvyVTCYdKxNYV+J9beiSsrIADQWdj6yGSbRWpeY5/cVHBo1L6cpORgU4sn bGkc23Lq0Sqf/c+xa8mlFXQWBwDA4wJ6b6zpSQffsDjpKxV5dx2dPa4HV8nY5bIZ1M7ybL/j /2/P1TcT92sjNT9beey6/eMKisRRJiXGy9rB8mZcs+TRTlWoo5+NmUN+by+TLxJ3eWxGX8vz TLM1a7YYmS9d3Kd01ycY/sPQMSW6bEB2K7Bp5OokH2f9bWdjWC0kua80+mvpbN+7+ww6Ak8g 0vkcHgBsGmOA0iuKxotQJ3s3c3RGD5kpMyk0YsOzDNOfVmk5iMV9chdIMNSzDX+Y2yG/BRkM SlVFWcBJvbjmFoWshY1JtjoqW/f8cjWyo5NIZXE4AHCYDFp/L4XFf59SN2AzGQP9vQNsPp8H FMV9LoNCo1LITGkunZKsQNTpn428OomdLA4HAAB4XGo75amJxpXgiMxWAABgEECNk8FV74cJ 1RQGV84QrbWhNN7ilGP2C6z8tLxTPk1xP/3O6hVm4RXY/onpWQiCIAEEjQ+lmtt5RTrnSVQb 4mMP9wCHwHL5Yq2zs9NsPr3Q3zogs6RtyXmXReL+uQchBQTpb7yZMT6fw2BxB6WZNAYKPKL9 HW9n8IenZapZCmaF4zxOjd+D8MzIQpp8vz3EFneN//zLtvMhkcU9/OGJGUggFE6P8QfHJqam IQiCBELBVJufmtbFOzci5zX3gVwnh2sG28yejovVz4HWJ9E+56zD2MOMmTlpvUahUDg5xGlP uJ8QERmjoNDyegTxGlvWbDthHZ3QxuePzYiL046MDY9NQ0tglkNoiVTd7FGIb+VDvaUx/vqb v1H2yuph8SGIWJgYfUPnTiNEX7AYP1xx305v58ZTd4r4fSOz4rkWzArHuOxqj9uOIe6x7XLt 2XVtsRdXf/ZXVYeyzJbBobFpCBIIheND/JHxiek5COKTmtIv/tPIpyy7fVw2rtNjgy1pPl6X jlx+CokP5pKed8Tc3HK7qAbHkdYFFQqFM6P89sdmvq6ONoUQJJiDeiKdXQKcQyqBXNaV2Zlp JodS4HPrQVZFJ13iNoQJQF28c90xCzNveHQMsOlMNnt4Zla6RkfJ0422qgdsfDOa+yWGockh wGUxOAAsnt7l1by+uH/N7oF/2dCwZB/NTnSXRgbcM3B4CkHDEARB1ObUSJ8LthHsYfaswvJm t8b6xkfFxC950kXi/gXUDXSwTHQmRwGXwaKzhyekhpYg7gc4aa76/HRkDZY9Ia6aKhAKp0d5 rHzP2/6evlIna/0NjTSP7LXOYo9IZ2FudnqcP9AXb6rpG/+seEFSot9F3G8Ovxfs4fqwcVjy 1ASCIEgwOz0NBlhJ1/2SKhM6IQiCZqcmnttoeIQmpWFG5id/dmJ8qL4q01blj5stlyzuNxUm BNsYPSwGE6PzEygQCqZGeawCT9/YmIRKCIKgWQh6Hoxyd3NOawBjMxAkDs3U+FhPRc99lRU7 Lf/t4r7/pT/pJHbThgSS4EwNsVgMOmdwfPxtUrq9WtyviNT403JVh/BC7OjkHARBQuH05GCC i5mbu0+hYu6gN2N2oj3Vzd3oyLlMaP4JC8QcH44xWaHrmlDZIlLdpWWcWTzZZE2c+tin3hf0 whldtIlJSVFgUWHbZ04mnm7ekQQImh6Hiu6gPCO8nuLl8jzNTU2P9fSTHplapNc2SKZgegzK NtHdrYYwC8sC4+Lpnhp9kRjkf8PYvRviiXog5NVH395jW9LaPzQp3VaCqVEuM9dB9YLhG4v7 unrqxw7cyeKMzMwJhBAEzUy01Bf5a+50L6fyRc8Q2F31qcZ7bTPa6wYmRc/bRLVqWyNNjNXV dr2RuN8QbOhse9v2CXf+sS4Ezc1MAio29tJ6y/tP07vl2jMrHoWe3fLFckO3ho6OoYnxGQia mxGMA+7I1OSMAGLX1T/xPmAQ0UpgT0hexxBXGw69eOH8+XlxvyE4Osj7SlizrF1IMCuY4nKZ 8W5eSYlp8oYhZk916K21f/9a3T3qWQd/eHxK3DN3ZHxy4dPHd8icQDA+yB0Zn5yZgxTFfcHs 1NQwB4zPSYJBH+ZGXfr2pENEYfXwuOQJ4sx4R3iAj+8Vjxpxl+TM6OD7pk650sUgNjQ3NMgq j3QLjUutfJ+1Tt4hH5W47+h47nY6RTb7eXcJIfj0duu8nEYyAADgyrEhJ3/46dftuw4cV+Tg vl27N6xRcyzpbV/quTNK94ucMIeLx9WR0t50dfS9UvsGpD+IGb2YjMs/HNi9fdOeBZaP7D28 e8PyPY5hz9vlf0DnRKBvG2ncC2+h0F+SOpxNbWjJu3VoFfJuWFl1LwCASMbF227dpIuKfVwr elTAACDdWfXAobWbti+wjDhyeM/K5Xuuh4WWyifhrnqU7my0wSi8qIs+8HYlOtuS3UJsjU0y ORRme9TlXfu++W79idvBHUw6t9Bb+7ytw6OMBdH+oMX9Y0Ym6OQyBZ/ZbfhGH9V9jknP2+Ti 2BzkamOuczW4CrdY6nCAzfW2d7x86z4O0BdcJT6+4uDoah4nVoervbRsbB1RmYrB4rEZ5Ka8 uo5eLAUAbElHkNbXP2zesfvggqk+sHfn7l82nHSuoHSK0m6wKYzO53n2hvo6qpLWyOPHzzun 1ismZGcQCKXxMRY6h5Anjohbamrr3w6spuEWJCZ+fV5P3E8K0t1mmklunHeJCUBloJ6px/3Y fAAAoAGQ6nhs78H1m3csXN6HD+5Z+dUe88iI8pflmH8ZbBa9vSnv3m09HQ2ZWBq4pGfWyXe1 BHF/n7GJ5e1kxcoe9J6OAvNN5g+LUlpEX22J1v6LulVUWImi0EwoT0kyP2AQS61foOa+tbhP 7e146rr7n7t37NxxaEEclXcc3L7xK6P0wuZ+AFrLEnxMt+r5dNMwilJ5Vbzt5WtLTcvD7gWt Luf37Nq2fofywlvjwYObvvrqtG9hVhcAhNLWONMfjvhkVmEUN/GLuHj0tc0vK6j7e4n7PQ25 oXYWBrIOXjZ3TigB4K2EfQBeQ9y/43j1rEkKnsmRPr1q624N0lpnFVfa9gYJgVj92NaIqyYG 6rKD2fbj3/YbubkVyjbsJzVkpN69oKpyQtpMS9/4bhazizzfGQCtsZeR1o7BYY2Khtj0AUxZ TjOuv5cJqDUpmRab/7Zy127lowumevf27Yc27bZ9wmSLO27LafbT/V7rUUqDXDmDzFvaLn6h 0rffKl1O3LLzcsxWvDEOYBufXfv+qEXYG4n7jZGa3xt5paY2yVkOuOtibf64XvwfjIpoq1tW F52iqYAjk3WdS+kmpxoiDt64s2Rxn9LzIsdp6w50VnX5gqd3tNqUQrT6FofGqm65tHiN/lrm ZvduRrbi5TPji+iOuXTdGm3xSHFWuKRW8oPDv+q7icR9FqG51Wnrtu07Nu5cuPn3KyvvXLbs QkBZG0auj8YkW3MLw1vOtQTOe06y/5vIi/sLL2dFuhsecMzhcOcPVtCxoNxK3TggPK0ZAADI HSBJb/fWHb9s2bcgOIcOKu9eobTHKqmhhrxY9++ET1Pcz3FcfTi0Ds+R+0VdYGXvE2H/RHzY Gaqwv3Hq8KoN+9QUUVFT279hhfJV/9wyziLd/xbTY9BAY4Lr5av6sh3eDSxsJci0ao+6YYVc tWLHAstqamoHN2xQvnrVr1xeW+ohtj/U/Oa0T3YHFiyuEgiFgpG+UMeLRsZXg58NQBAkhKCW 9LsXTfSs7hSyJa3aSiOttL9a8aua2vEFlo9s26CsddUkTd4yr0eQoHnU2Ncv9+2SlkPQMLmj wuxniwRsOZn9Ig19bd1f/uOvh+88I3YP4ysf+1odvf5oCOIu0AI+XHHfxeLoCZe8IWhY1meh ABpJ87Hzc/Eqkosju64tA7Vm9+2MGvpi6Z6GaJ2FHjv2elcTOxdcHW1NK/U22OnV28OegiCI VhGVaHXsWPhQL08xWON0TD8Jj2FDkGAWKre9qnVo9cZFlreq6v71/1I2DSyoEC1voRAa6cWk enuYnj4438zwlldKgcIzptlxAb+rIfCWmZH2EXEzdTW1S85JdU1Ly7cvx2uL+4fQoenpcg+f +mvjQl3O3EkWv5jyoijE4uTyn7Ysury3rlPWuXEjg7a4gZcihKAROiYlzt1U79B8b3qWvr4K T+CWIO7f9zm3Tfk+rY+rKAPj4myCvd2cq8X/rPU3sDY1vpKkeBuam55odlNxCsuO71J0963F fQEEUXLunT678+eNhxYEURWptv2HdadcHTNIEDQ4PV6M3nvGI664VnHiBoj1EWYrNqOWmpaH lZ3gaLB9+UZlNTXkAuN71q1DGjv6t0HQ3BTUhDa18ECF1ipmOhnsGSsy26+M8v+3ivsjDGpt ms91tTMnpd4ZaJ/2yaLxFiToXiqvFPfrYnRWGYXX1pClt+MZCMrxveXp6ZlPWOQbr2GyKjLi 3lm5v0Lb1u7ae1AvVVbcn5yb6u2ItkcZ68q2tAyrKpVb76wXyZ5eFwxtaiDOgu3MJ3X1Eonk UWhucoQSqqmF2L12x9EF84xQUdn2/fcXPbJbxB1Pj0HZJlctvO7Et8nuBMyTiEe3jJzbId4k BEEQ9fnDxzZaGtFDtCHFGyMm+qqtldmbivtXHVG2znL/Fehur310ZqtzCZUPIAiCKLjKx2ar NQO6GCT5591jL4J9b91QWbK4PwdB5Cc2Zp7uwakL/gcimBhihp8080wKLJerEsCseJSA0j58 70ULb3LhfRS0JKZ5Gm+/U0vjKT7KGytCO9rckor7zCc2KN2d325auPmRamrb1qw5Y+L+tEOu A2ZPdYLtlqNWz1rb+UuuKvDukBf3F14e5sdc2mYVmd8ud+PsTQh54G+Mlrx02fTA6+rx71bv WnhnVFM78OsaZf07kdlvUHLjI+SjEvfd3C/cy5X/qry4312C8Ud++Qvy5DkT60W4a+cQkPqC RnzNrPIyMHpam1PcHO7aiHsyN7c0Mr5g4/6ouEOkF9FIXbH6XyKQ2mpGi1m+Y2ftlvq8nSiv LeVEeLhZGIfVAPByyY5Mxmfd2/6v03eio2uogFKPzzbf8S81m6iyanFfNABi7x5BIPeq6y5m 2dra2jn6eYmCqlX16ImfxR6nGtJbSvsAUCofpQXaGN5v62+Ltj1xdMfy5ZtVtAxj/n/23jug qSz/+9/n9+z3993dqbs7JYw64+hYxz72MnaNYqRZQBQBsQACCoQihN6bgNJEQFCQjoh0FQQE qUpNI5WEVA7Sa7jPH+kJKKgrzs59/af35JzPaTfkfc/9vOupjYGmJ2ydA7IblT7ySYv7apbo wIcNSoHgW8JO/oaOy6uTi7j2hoebl5HzoylqrM3wcHO+4HIPgEmCemDr4ektyX3/wHb3FWtH l9w3RthU8Mpf9euVqsfPGk82zw6OrjdTX3ZKLZHZHaAyPtzPWVzAEo0+a3ThqktYfoGChSq1 iVQQjrlmKy5pZmlpoG9oE5ja8OIds/JMU9xPvXnqd+t8msw7LQriPh2AOJud+1R3qutMtbzj Hj99mzPzZLABqMwO8/WSqcrI6MJll3A519+ZiPsWaBf3PMVmWO2Nz+zXXLpemFAl/GhdrNYX Zz0fCP8pC6k8OdN2l0YEvRyneOm9xX0S8VWi3eo5B9V0dUwmvTW6oKNKXuI7ACjNve10YuG5 MCpTSRetSX0HQ10WETyzPbHjwF6kzoUpZjAk6+ULAgCvHtUEnfjsaPjD50otN6coGerK8KHE fQCotbmPbrlII7t0yeyi2WXvWxlNHMp75d1+q7iP8bdWuPru4j4TV1N+x+W82hE9UxNTmXE+ vnmu6gUFcR8AJpZUmehvZ2svKnX56lXDs/q2LjGlZSKT3E4ASq9rIS0dwuLeqGe3l95NuLTy +y2nz1ywmGye3V19kku5PJFO//Jh3Q295VbFCptXQdzPuLrpsp23l0LMADBxtaVoJUNdcSBv E/drb6svd7hXKn9VQdzPCLlw+ZKOT7LCox0mDpSiNQ5aOs5Y3G/H1aZZL0UFl1YrPSIBoOFB 7Q29pZaPS+Vf26kO0nDwjfQpnLzG6iCN85YYiztKgZBfgWipoS4TW11qvXTTPg1VXdPJ5sUB jb71sJmo8M5Akr2D61XfFDkn+U+Pt4r74gT90qdDCuI++SWIRq3bobpPy2iywbFDo70TnuGU TZ4/Gv+d4r7QUJco75GnIO7nW53XUV93yBAzOYEJj5vb3iFHNwRxXyQlhXtKazI2trBx9Ust kQigL8LOX1Vft/nUFC37Jtx/0ib/o55AbL6tvtThUQtzahF1AoIIGQ5njE8ZW+fxoAkBRLzp qKd/6lJErrSuF/kRV9V/2KKBwVhP1rJn+P3kavmW+QTBPXU1t9zUt1navpURHoGRoHH5Rk1R xdP861eQ3y9cuuz7QwFPi+uyMyO8dI+FNUGQsjbw6Yr7PtdUT0TUK8YsgKDcUHs/D7eHchFz Kl9muy/XTMJRlBIPQRAEcWgvsx1WHIvBUSYJCp/7Mtp0BaYBxxqEIAifeyPUcNOx+9DkNQkZ H4VyLc6eUF+vem6q5X3vaStWNkc3vepFxk2ZAuZW1letXWJSm+W9WwXjED4383aAuJgjBmNs fsXGLSz/ncdzeuK+0FA3K0dOmVEQ9ytzQizU523TxGDQk/XZKzL1rc7MU0DHVWXclqnK0tLa FO3qmdbClYzOTMT9kHPbTiRDyjnSKak24QGe9kWifz4P0nVGW0j+KUEwMth6/bBjWPbtOsVL H0Lcb0mxPq63Z7eqyRRrJyInv54JQZzhgXjTJWe87pYqJZlnk9/NUJecHHtNb8MK1QsYjP1k LV9PyC9uh6DRQSjHVMfM+2qMUsu9JCVDXdm4PpC4D0HDoINaEBzg5SKKzNbW8cIFE0xgXBme +F55t98q7lcnnFjnUiR79d3FfcHYCKfy7g2bixfOG5nKjLPxiX3qBxXEfQgSjEGcivz4UB/p 3r9kZm57LejBA6kdLflZtMs1DT2J5j4pY4M9LQH7NdTV9526Mtk8u2Awd3KbaSKZdKQfyr5k 4XPXT/5ho4K435rpG3Rh76lU+ZghCIIgUpKSoa44kGmI+xbBfgHyVxXE/ZZXxUHH/3k6isSi KnyYlBTlfE1rxuL+GAQ1J5rZBwUkPFa+ONwLPbho5nNX4eEiqzQq1dPwdBrEmiyzP6s0Ku7a sY3urxjKhwPKfGUNdUmJZtan961BmU42LxgMJjKx+JX8DY5FKE/FbDoTx+DQZtDHj85bxX1x gn65t6EUxP1nPu6X1BfuPDPF4PhFZ1Uqmzz/V/LfJe63l+OSzi/f5Xw7r2HGuXdmREdze5Gf /tpV2q4pibUsAACL3FZgsVzHPia0cPotT0fcBywKtsDuN5S2PebO08YXqblXdy5SDYp80iI+ IZMzQ2AAACAASURBVMwCoMDvmI6V3c170391/MOJ+6D9UXGKv+65uOp4g6M79VV3bNPV37f6 XFxFvMFxs+CAezXKn/ikxf2DxhY+GZUKlzgvcdUBqB3OSYVKJ/ffJO63ik7u4yY9uX/RycXD PEE0AgXOSBMz66uJiue+5SCUNt+9sGiHy53idxGzAegEIP+W4e7jpxze0hAgkFti3bf9fPBy QkTxOzX1wcT9TgDyvNVOWGEik94c8oegLPKs3nHdE5ZJOImkNZm4z6e2Um8ePmYfqyDuG1vY OWQpikCTntw/4ZgU80xxpRJKkpMsdunG0yv/Ayf3yc05QftWXgjISmt48w6pf3rX/9J6Hf9W RtuHOblPBg2BF49esPFLK32zQIZ/XB9/af6+gIyyttk5ua8M8Ul+sLnWxt2n4rE1pPdxEf2Y 4n5nS+Gdm7q71p0NTarFUWQuZFpuMbNVEvcVoVNaHtzSXvq7tk9gxksmAMKT+5Gn95pY+QY/ e9O7PLQX6dmuqGWn7+XUkt5+G56euF/qjrzq4Oucrdgu471O7k9H3C+NtbxqaeASSwc8hZP7 qWff4+T+ZtesiilP7mMmObn/BnG/Je6cqfU0Tu4T6+v9dyKNgoOzXk37Xaw/jbhPbwY5RnvV HLzin830/a+Pw59X3K/ztjJ3MvYu5CjX8GGh59wyO6mrZ+daLvrZjbtn5WNron93+i1PR9yH IAjCpdq7XtJB2eUxJgAh8rShvt3Fm1Uyv2VxZfE+V/YYBjAg9jRz6nw4cR8aYgoI3lfs0lJv uIZYGa1dqu1m/MNqw/CwG65h192OOT2b9EOfrrjvbo1EBZZBkJyW8oaT+28S918zmgq8Nm33 q5j05H7aE7/Tm3zbhSf3yUWR4Re2bg9iELlTp/8QjEG1HuamTuYBj2f68okYbG2yneX+A9uD GO1KB8xlW4KgmodOJ86dtDif+I5NfThxv+1ptOfVgxeuM6E3hfwh6Ki+F2l54Mffr5eRxba2 U4j7A098Iv2dFcT9IP3NqrdfU4HiEWPlk/vXLIwtHijKdf/pk/uFHhcxls7elW82AO0eGShy 2TblyX3zdzm5X5Di76h70jv/NdT3hoQe40NQtcvUJ/fN/+Mn95UZZA01R1/duUXPNSW57X3O L39McX9sdJD51Bald97BKa1WVipuy/K/fl5J3FdEAEHUZyHnjE9fOOVX9RqCxiEIglhV8e6Y Y5qmhT3s/imncHy4jxp/6tzVQPfUtre7zE5P3KcV3oxFa6jF9kx6cv/au5/cf6u4T8M+i728 WD2kubNd/rYzUB8eYPnuJ/d9vcJSlb51BYM9rOjJT+6/Qdx/w8n9AYWT+3lOng62egEvemRS cr2RP5O43xwV5GSvcSW9U2rj/CflExH3b+puuHwzrbJRqJ908UEnlUzEE8l0qaQ2HXEftJGx UZcWajlGPyzskEstDXhsNoNKxLfTWPwpUuBMBZfNoNMp1A4ukHk9nceivCq02qhpHRb0CA8A AEwSSLmkZoSxDi8ky+W1BXwum0Uj4ok0Bpsrr4lNS9wHHBqocj+3VeustZNXosulVfOPhROe yavi+R5qaCsb+/tkaqdskHw+j9XRjidRlTKnf0BxH1Q+eRCss9rQ12jxSh2Mk4PdPbtT3y0z dDdafhAdfj13EnHlkxb3N2vpWoankjtY0jQIHA6+5EWC9Xb9mMLnSjn33yTug8o7dp4mmnoR VEInXzIBXXwep6M90frAVTt3P3H+65e3zxsaGKhdSyV1cMUZ24F4BnEEEr2jkwtAK7EpwuhH Dac7ecWKy5vF6qAQ8SQaW7S8eexOJoVAYcrmCu8CgMNMvmpmjtb0lCbe5jDpHTQKlSW/cmjN HWFquw19XBMneTwzHR7YnHR2871ZJbUMZtLJ7YR2ApUl6eA0xH0AAMhzPWRlfc0xhSKTTFk6 OCQqgzlTYwAem8uk4CmKDhNc5v3gy+bnjnmlS7YkNiMt0mm37u02itDnlsdldRBqnjwwX3HQ Ilxe3N956rSe4Y1nJIZ0BvlcVnt9+c2TO9wS5XLu7zF09Uqrl03xzGN11GTFB5w94vSfybnP IjU9d9+uaRHon94gn1oa8NidHWQ8jswUenI2F6ZFGe43S26pInHFejYfgE46KcHPQPPYjHPu swB4HmWgYYX2v1lGY3BlZ5DH43ZQcDgync3iAgCasY1RZ9abRWRXNbJklHQ2nZbj43/x2Pvk 3K8P1V1unPWoTujcC/g8bicFR8STKAyW1LeZQqZ3MOXHhoN/Gh9rsn2tXfFT5VmZAR9T3G9+ lhhqu/dsCJmFFdUmGue4i+svWsuJ+zxWB4NOJTOkafQBAHwGtjPvsoYqGhNZJEl9n+O454zB RZOwChprkhkkUphMNh+QK16mXtu8xjQ4u/Klwp7kMJlUMoFIY3aJHb+nJ+6DHHsnN2+zSLl2 eWxmW8XDIOT/v/0dc+5PR9wHZRFOgTbmzgU0Ok8cM49Nf/U0y3zZsvXvknOf2lJ198y/9Vyy 7pazZPcxj9VRmRLkrrNeN26SnPtvEPdBfYQzxtPCPVN2BvmcTnJdYabJL0skOfeFaeWPmNsH Z5XTO7myGX54bE4HGYcj0zlc+c0zA3GfRW8nEbBYHJFAZnBkV9JH4P3FfUAB4K79jjO2HvGZ VAZLdnD4HG4njYglUpncSbftx+GPJ+47emBsk+slv5VHBgZe89hcHhiExoQ/Rqcp7kNP48zR 6PPXU3hyqaWhiXFotBdw+d29gzPMGCsYHx3q5XJ7h8ZG5X4WD+OT7T1tLutEixWC+rgYb/S2 KyksMDg6JtPyxMRYPwBd3aB3SP6n43TFfajjYSrGZP96g9uvy6+prjC0jY2Wd70lPY2JMt2u Ec562TEqY/02AUFjQ72guwt0K1iOfkBxH+oSCNJtNTHOJ/acvnh6m3H0WJr2hh1m+lr7zOzM Tt2e3I710xX37S/u3GBxiwWYo+PiIRNMCPp7KgOvuUX6yLriQm8V96Gu9po0g2/0/Svz2oZl BaLxod6XGUG+RnuNskQHvXl1qUn2ql+rR5S1sIek60w0g138Ln7vMAQJIOhxtLGVjUloGr9X bnkLxidGegGX390nSQ89MdzD6+kblM8VPj7SkvXE7+wXulkt4hPmgrGRQcDqHlBaOSX+gRir nZiSmY2hGFzOnUhjLavywc5+kWXw2EgfYLHYXX2D4pamJ+5DxKLIiMt7jkWympmTLW/Qrbi8 38rEBDTU093T16M4Ok2vin1Vvzpzu61DJGn1U4frnVBnb6YU4ofGIWEa/X7Abbhtam9lppBz 31t71SrbxzWkbmlS8omJsX7wOMgu2C8oQZpz/4yZntax4Be8PqnzgWB8dJDfkWJ2LPBe3n8o 5z4t28kPY3E6pJrXNzomTS0NTUxMDPVw+aBHOBpjw4NFaDXviJQM3ICMdjky1F9bmXXtnXLu 06oTfV1PnLZ7zCO/lr2LTkDQUH83H3T19A5Dopz7tt6eHhm1vTItjw2NkJ+3Bx/+5f1y7l9x jXLNbJd+w/R3d/O43C7JPhobGejrBd19o5DM2IyPD/NrPPYbOoQFFr1PYo6PKe73DvU9D9iv G5xVWi1a3aJxroxzcteXE/cFYyMjvTx+7/Cw/HfbSNudcIytllFCi1i/xucG+xtt22T7tLlj YET6BSqqmc/v7h4Yg8aHIFyE/Xl7K8+Mmu4BiWsCBIkyxXM5oGdwRBTU9MR9CJ9TFWO99Zpc uxMCwdBrbp4LyvDsO+fcf6u4D3Gaq1IMt1/LaK1hiWOeEEBDrxtjTYzeOef+TT1XezvH7N4h ed+LPhYx4fyKq0EPUuUf7L1Z3Bfm3N+pe7uZ3DUsvecIRvu7GqKMDPX1pTn3qZlxHo6nDMOe 8vt6xwUyW1AADb0GfAB6B+X7MgNxf3Sor5fPYrFYLG5P//DYR03I/0HEfajqoZ+LxRHHGM5r 3rhAZnULoNG+nq4u8Lp/8M+h+n8a4n6bv+6cH7SsUhNeAAAA6KSAFOOTu1dsOeMu/Vk7LXGf x+9oJd/QObL1xCmPRLlfxLjcvOvGO5cdtstpr5vZqf5XuSEYJ0MLvxegQ/rzF0tqvWk0f7WR 54OMZh4AwgcS5Pu2qupap3Tkf4tTa3OzbXYt3WkXWlgvLzVMT9zvYgNOcfCprXrquw9oX9o0 94RvE6VZXlxj0e+HWamp7zhlmiqrblNphGwf5OIjJqHhCiLHhxT3OY2FaV57l2xe9b870InR T4ryY67u/tvytUt/0QnOzmyeRAX8pMX9I9uXz91z7LRfGgBiWbqy5L63wQoDv3p8s4Kr5tvE fQ6z8GGUw/FfzaLb6ZIJYFOxVd4HdulYOUQ/pYvb4DJK77nontx3WC2gWkZ7pVKxmV77f1mv 4eiTXAMAj0drIoccP7jp5BnflGLZlrAPH/pf3L1SzT6fJjyd3PrkfpTROv0YsszzCDYAlTHn tp01wjg8kD4aeH7H0d9SzyIdyDyTolJaUr12fKNlmxpb9o4Hlh/Y7D6qoX3SVxJm3h1HnX2r Dqy3SKcyRKtumuI+i3Yv1PyI+i59i3TAkC5YCqU13XPvAlXT8FszddRtefwy8vyis7G5VXL7 oiFaX0/PSNPxgdROmfc0N8bq6ILDDgX0xg4AAPZFtp/Fum9/+PKvP50Mkhf3j5/aqvIrUl0z qJouFr8pVVmZjoe2WNzPqSYJxU46tjFW69c9v323WtvS5p40/w82OyDYzgDpXIClc5WfPr6/ uN/FZ3DoD/1ObTuqYyXbLgCgpfheoO6Kn3RvFVQTAQA8fGl19MWNc0975FeLzbDpACS5oNav /McPK2cs7ncBwGE89XU6dRSpYXe9BrClvWvGNQQaLvhR17kgrRYAwGMSqnOvrN921iMgvU5a Qa6LrcaKr75b+T7ifrX7kS//deJa7gthvXRsXZLhgi1LVY2C0p+Ihu55lNEpJ8+YRLmxqSiI tdFZvMc4i9JAfR957yOL+5jLm1ceixE5JAPQ1FrjbzB/3oLP/metjpy435blHeJkciK4plOm YVrri8TT3+w+HxT6SPryBosWH3Dx4NG956wygYxsL6p514Xo2CdEwOd0tJRnm6/dtM/UJvZJ M5ChPDrOQnfVNqtYFkckX09T3GeVJjhoG508Z5UJJHffpoI4X9Q33/zjLz/p/AfFfU5dQpyt 0a7N1tKYG/NfBGn+sHrRvEX612Yu7vN57UxSgNnvFxyDsp7K/H9rhqeL6cnfzkfjaDyFvf8W cZ/LyAu8ZKanpRNayxG/X0CuSLlnvPr7L//61+22InG/iwc4tMeeWsdRuscdk2tl9evG/Cpf 3XlzdD1K6hvkW56+uJ/jcEBzPQLxy85NOqHPePyPmsDmA4j7fACY1DhTo4PHDpnefCDbX1JZ 7d2r237YYhFXVTJ7jrp/PHHf+PDxg2aO4p+iUMOdu1b7l2w8YJApTlQyXXF/qP9paNi5k2uQ rpkQJNVcBzqhJm+jnUeMfbLzZ3Z8s6sTm+O9fbv3I7y8pPUkxuz0+ZOOQa/E+uBIf/PDGw5a a1QMMpuo0tQ/ExMCQqzhuVPGRv4F8lL3tMX9MeLzBLvLm+Zre7lumqd1NSK/Qv6E/thQc9PT a+r/nKN3vUlG4JqAIEKej4GxrtF5BUfdDynuCyYE/Zlmx05v/Wb76UvmWfTx3lsma/du+3E5 yszp+qvJz1p/uuK+l86ynzdtmGcU2UoXL6mu8bF0p9+N3G/llyu4Db9N3BeMsXrYN8w2m/jd LZO14u3I9Xa5YrDLOq1L/OxqfIROrAy/vPLb/TZZeU2S2gQQRHjkqadzRPuIR4lQSut7HBSs f3I9yvMBBEkTwPR3jNZ7nt162DQwr5ApbHrksdNep5CUe3IewPS6FEd71R1HYgcpQKTw8Im1 6ed+Mo/HVkjTTwggCP/IWeuyvvnVh1On4XgjuJwbbprL/23woLVDmNCknVgbcHbuj4uP30x9 LtKLpinujw01NhTaqn/7s94N7HOp1CSAIHyOx5mLp41NZuqoOz4KFTuYY0IdE+VGh1eTlGB3 5CtUXAMViO2U2SO9Mcar91/1flTMhCCof2y4Lvr05t9//Hzudl15cT/WG/nTknVzt9jn5DeL ZlAwOoSPPm3mGOiVhZeY0z4PsjTbPXfFvt37ApopPNHw9tMba712o+zuZ9R0Kj99/CDi/thg y9Pblkb79uwLaKbKHPUdGx4surZDzcDO+X4TBEET4yNDNd42mhcvYu7LvHdTWxB56ci/v/vi 72svzVjcHxumPSm7YfTbvAP2j6gt0lvjGAQVRZkcNdB19n4GCZd32120lclFNd8y6acJBc+9 VBH//OKvCy+9j7h/eo+2mt09Sb01USYmu7f+ruWbDUG9EARBtBf3g7wNzQJboC4ZH9mhvvvW a7aZuGdlU95HtPzI4n5ZwP6FRs6pQodkCBqFoMKIS0d2/PPLn9fIift91Lpq7/0a3k8et8rl qqu+edbigsGZ8GaJQD86WF+TY4X6bqFeBPmFdA5GhDWrHzE3TyIJzXib4q5Y6GjvN09qkdW+ uW2v7xlsXWXg+LBGJF9PU9wfpeOfhV7ZtPDcbXKNxIt34HWBzeb9i/82Z/t/UNwfB3jWoyuH fj3n/qBG5DY70gcV2JzT2TrnV5T6O4n7w335yZ6Oxur+ORAk+ROtl1xd4b53+UmfeyVEBd/m t4j748P02kchWj8iXQpLxOnYxgZ7sOHHNdd/99kKNam4PzZAKQgLOndwweHrRZ2vpV8cI31Q Afr8YQN97/QKuapnIO7jHoV4HlVRmbtAZbN9RCmONb2h+DB8GHF/eLA2MevqsR9XWkQz+NKS Y/0QNszh2DEDq1spfw5H3U9B3O9kd1Q+u35aB3l4u9CNdj8SufawvpvfjcfVte2Ay6S8ijO3 OL5h2dKl8xYd0NLxSSF3tAPwKjc61GjLnpU/fL1w48ajDv7J5VgAAI8N2kqLbzujL5yUs0bb rXbilKVTWl4pgU2fmaBdl+V9Tmf5vMXbkPsOSutTVdM655yU9rxdNoM/saYoLRhteUbeNBJ1 Yr++c3RyaUN7RycAgFhDvG+jrYlCIjeuXrb05x9XbUMiRRUbOjneea4UAB8AanPkeXPVX39Y g9ykf+85tVPJNYDY8iIt3ueqIRKpKtPyYdT+45a3wx80vCKyAAAsGrHA68TFk0jktlUbfv35 X0u27d0valnb2NG3CDDeKa80sTwzTneRyr/W6UcXFtKotQ9vWK3+57dfbjW++7hEJLVzAXj1 wNfM/BgSiUQe2Ld726KvEQtWLN+4G4lEIlU1kGdD7le2kgEAgEgl3Pc8ri6cvF2b165Q+Rti 5R6Rg6yOia5vEU0kcL6sLgixQSKPIJFIJHLbqgVLfvx+7lrkvgNIJBKJPOeCuaOYXOctCMX9 c9Zm58yCrp6WnUENXTOrkLJaJlfYm46mZ48D9TSPHkb+vnLpkmU/LpZavR63DLr+SDZjOpVU +yADY6iBOiwpc+Dw0W3HLX3uFNW2yT5l6iDUP8u44Xbl+DbVQ5J1tvfw0YPHLWOup1SJCnNZ oK2k8BbGyuiE3CLbpX7yjLVLekEZkSN8BNVUEOd78O/z1+yVMd89gERu0zT2CUiukz0f+izC wnz39/PWIfcfQMq0izxuGRNfTGh7x6w8gFh9J/DqySObJYOz4dApM2Ov3KwyLIfLB6A8O/ya 4abfVs7598JN+9SdUtOfk0FHI7HY30R9129z5i/7de2hyy7+xaCTCwAgNlemxHldMUQipeMo DNIqNvLhq8b2GT7Sacyv8z745U9rNmyTsybeoWViHZj8pF42ARCVVJaQZLRrxY6Dv+9DIpG7 UCf1DKzD7phuW7dh84p9l21CchsB4AGQhda2vWJ8ztHF4th2yQzuRWkfvuCR8gxPZohkUjq2 MVZrtYmTh/FV0wsaUovZXeoGhphbhfU0rkika6jKDUKLt/PWlfMX/4SYtw4p2q/n3V3vinP2 t2bGe1zWFs3v1hU/fL/glxWrxRXruqdlVgpTs/AAoDaWPop2NpFtF4lEIjXPHLcMvpP/iih8 MsahMZoKc3xNDU+qyRQ6qIdG6xzas/OX+SuQp/VCK2twM3Fb7misK4kOdr5wbDvykMxd9IjG cSPX+KRSIpYOAAA8NoNanRPtZHjuuGx8esbGOno6O+d9s2Lzfj2X9JoqCsBX5ty1Rop21dYV qxf/9NmP6/YfEI2Oogsus51UkuR7fOO+w3uEppn7kKg1h419rieX1GNJAADQCcCz4GMbD6xZ uUZxbC6jbxSVE3mMmT7kIj4tjnE4g0QeQiKRyB2/Lf5pwZyfl25HHjyIRCKRJ6xDb+bhAWAA kBt5xVBjxeLlC39egTxz9uaLWnwnqM98GKi/6/eViC8Wrt2iaX7jQd4MBH4mFZubE31e7bdD h8T+qSjNk0Zu8cYHl25bu3TtMTu7xCbRWxrJjk7Hf/126fYDB2VmBaV50MgtIrumWS65DqHp +f3b7uYGoh7J1RxX0CQszGN1UKsf5viaGp8+Kj+QOnomniHZFY08PhuA+szgAP2Nv6+Y+/nC LVs1XW9mv8ADHLEpwQWlunuBypJfV205bW+X2MTh8QHowNWk3fOTb1dLT9PQ0k1t7pKV61Yd sLAPy29iU/gNt9wu6mohkUjk3j071i38/PMFq7cKHWSPnDirH1bdQOgEoK4iO8Bi5461iM8X rdt6wOJmWD4edBBArou5/q4Vi5Ys/HnL4bP2N6s5hE4AmLi2J3djrxmoSt2GtTSPGbkFntqy /fLMc+4DADgAtFbddrY3lFvfu9QNDR2jsitwfNHLU8T6wmi/M8jDh5A7fkUsWrZq2WZJWV2b sIeyzyQojRXZ4RizY9slIe5F6aBOmSSYbFi0bM2y33SveN1/CgAfAPqrJ08jHTFGGtvl5kVL SxvtfreojNzRAQCg1bXk+hqpHkYhd6z7ZdGSBct+k/xxcsLGIaKgeTJf33Tz9bt++stfvvh1 AdLnMZf/Pm+4TJMOXMMjJ9WzWkjkll9XLJr/xfzfDh5EIpFXvVNKpCmKSm4GWqttWLN83ner thzU98h+VUMFtLqCR17HD29b+P2PK1b/dvqqd/JTYY/wleWJvi5mp+TGZs9RjaMX0Xez8ppp 5Pey3Hgv/mjiPofyOCjQWGOzxI12h9ppIxv34tLqDqh/BOJW3bt7DbVr05LPEOt27bEWOtn2 stpLPVFGexcuXr568a4LJt657RA0BEEQIFOf3YtxvSBnjXZYHfX7aeuolJw2xgwtZHkdzYnX lny2YcuuHQflqtS3Do7Iw5JlUhz0cShNeTFBZqhTWrIFj+7WQbuH59RgO3shCJqYgOpibjqc Q6H27Nm1GvH5ok279osq1jZS8yptZyknTRgANfeyLv+GWLT4F9XAqMftSlpyXx9ofPEgyFn/ lJzpL2r3CVMP94SaWoqoTtyj0BBzFOrgHtQ6BGLJpt/EXTp6VO1aKunlOx1OnRAI6nzUNNeu 3XXe7y5nRDBGvXNm/Y65K/ebhGRIu8LBlcYHnxOFtW/DomWL5qusFFu96rn5JAklowkIqssJ sTcXGdod2bTgywVLV4scZI+qoa6lFr8Sqgc9gvGnt83PGaJQKBTq4J7taxH/Z97KnVv2olAo FErngrr3MxL77ckh5KCmJ950OKh1rTjwsoGOdAqPHlW76JaT18ztFvV3nJ7j7mGujTq4fefG pZ+rrNu9T2T1qqV/+fI9kkwG5BHBOLU5wc3xgo7srOw7aWrul1LWKpvBaXjwNb2lKDPIXEtf S3ad7T552csltlJauItELkm45aywvDWO7j6Lvp2Wi+tkDUIQBI2PjuRarETtWCNvvrvvmKE5 OqyshgFJVCQu9nm82v9Zs2mXaOhk2vVPaWp91/xWfeyG8vv2x9b/dvSQcHB2Hz2hpoV+eKeI QOf1QxCjoy3J7Yjqrp+/X7Zmwx5jP798BiQYh+gP49zOqa5dtfSHX9ZraNmmU5vYEAT19fJf VmYGYPS05cYRtfvkZW+ve3V1lBlO9PgIlHP5zJEdP6/+Xba6g8fO6diE59QyegclGtuwYJTc 5HvGQOPQxv0oFOrwUbU9p2xiQ22NLqlvnbPhuJZ5UkVndy8EYR/euWlw0CAy3f6CxlktsfXv UbVdp2yCUirxMsmJngdZe185d9E/3PH0zuPqquIJ1Nlr4J5cRmK9Fj5Aej06XBxlom8gDGzX 1rUq/3fuql1bhXOka3zMr4zG64cgCOpuIxQGXkShNFEoFGrvtjVLFyHmLN6JOqiKQqFQOpYB gdIs3gNd9JZniWGy7aJQKNRRddQlj8Dk5820bggSJqFqb8m+4X/1rOzg6JqYXLQ015z75YrN e9WdUmbmczDM76Y+K0hzNFU/riVvi2xoGxT+qFniRjLAaKm47+90Xq7lM2cu+vporpy/Yt1G DdPAtEIGND4yWBNpbCMcnQO7Dq9V+WzuqnVbhYbQSi64gnGI1Zjnfem8xk6JaeY2tfOmjree VGAZEDQKQRBELotBG62Yu0Q8dELU1DUveaRn17PekF1qcgZZgy0xzoanTqJQKNSBvTvWLvry q0Ub9+5EolAo1DHDq1fvk9k9IxDUWpUZcGXXjrU/fLVk814Nl7T0Oh4EKANFLpf0fl++YNmy ZXu1La/fJ0M900y5Bo2Nj7HbKz2cDE8dlVndhnZBFhf1dTd+M3fz8TOhL2opfRAE9bZXlaGX Llm7bdNOhVmxc4kpbqDKbqveHm59eZrfNd0Tct67KJShXVBoVoOkcD+juSkj+MZVbXn/5OMa Wpaedx9XMbpeQxCgNBa6HD6z46efl61dvu+yVXAxGRobhaozfa3Pbli9asG8ZftOnL35oo7S B0FD/V2tL/P8HM/ItKumgTL2tDuzW/P3X+dt0jlhmVzN6+1jPSu85WCAQol8UH+eu2jhErth 1QAAIABJREFU8tViB9mzXulZ9XwIAkN9hWHnTx9d/vOK5cs36VhZJpN5vaNQa2aan97O7at+ +GrZln1nXdLr6vkQNNo/yn75PNrBUuo2rIZCGdu5GOkZXZ55zn0h/M6a9GSMkewAHtLQPWDk mVDcxhRZ1w4M9zdlOuobn0Ad2Lpq/dJ5c9ejDhwWlj1lZB2SQob6xPenodec9rIUf5MjZzRF M3jkqMauU3b+pkf1kBu+XYw8firwIbubC0FDPAr5aUKKg+4RLTWZyVZDoYztg9Py2zp4EASN D0PUzFuOxrqoA3u2rV/8z7lr9h8UuawfN9K2Tqnh9ynfalvSPG23/uUv//fvf1lg4l/YMlNz 83ejJd3L1wSF2v/7wTU//H3O6vXb96FQl8yc7z8X/hEIQRC1ov6O2SHk2h//vXjdZi3z0OzH ndD4UB8145qD3taVK379ccmhE7pBD7mvuRAE9TA5tVnJPiY6xzWkY3PkKGqXrnlAbMpLEu2P 9Qf1u/IpiPsA8FgAl5sY4uUkMjGzR6Mj0mtacaKLHbhHISFe19BoNBrtgnG9+5jeSQMAV5Gd dl1se+Yak1T8UqrJkZ4V3gtxlTNG8wmIelQFwMzPIZMaCu/FyNeFRl9zcA5NqWcQlURFWkNh gUJp10C3ey+kp0qpLdSiCBdHu0nM23xu38qdQjF4mfMg2vua943QXNwUSUhohPr8ZE+0xPQX jUbbY9wiHndINGQOg1qV4OzvMknLroG37r0AU518fTOdhPqaZF/MtaiMujY8ANTmqqJwewe7 COE/AQAA8ADAld4LDsFMZlln64D2TC1qbKcDAACVQSmKd3Jwnqwg2jXI/d4LhihlB7a5KjUc jZ5sHNFo39joXGUr3zciFPdNgwJvJNbn3/ZEo8UD6eR9MzkPLz1U24mvr7nv6Whvo9ys0437 KeXyueE78bSa+9cd7a9JZ8UJHfmkDjuJak5tqiwMR0t9bdFoeyePyCdMxbLtpfkJwfKLzDfo dt4LGUFTuSohwRl1VfLH3LFlGSlBisWuOXtGPmHi3lXZF0ZZl58QLROlb2xuvnROGsoyoiTN usU9fvKKDpg4avX9QAc7oben6/WYpGrJMWEarjb3vgfazkY+yKed7xIkpYlUEOaoPDohWXlV Si8ByBd2vR6TVE5nl9+56euEdroZnlqBB4APQBZa28M3OPBhRUGYzLC7BXslVXfKbFihuO8Y XxiTlp4sO+y+cbH5sofGsY0VyWFotFKISoXbS3LjryvenyTt33lSIp9Ppq00LVl+uh18w8ML 8GzZM8NcBsA+jA90F+9XWzTa686Tsqy0+FsuaFuMu1faq5YZy11tr8rvh0m3FRqNdsC4h6c3 chRqan8afydI5k7hdic1J6vo0S0PURgtjR2A8qo8P0xuMcjgFxxXUCN/4pjLIGGzAwLdxa6x Dq7oqJJXeMnIcAHAPr0TEKR4g3L2jUgrwIPJjwW/GWptdc4tjynmxTksNf05WfjGQFaoj9DV 2dbJwyu9qZXMBm0lZfcDJf0PS3v2fGbpwMlUQl6svZ34+9TByTMyvYnzNCU0whPt4BsRWUgQ HvSm1jzKuaX4fWDn5OmV3tQ6iYMwte3Fw0QP2TUpqlmxbH1maoSnQocjMyoJYmm4rSQ1SdI/ 9/j0Z01kQKYS8mLsbIUxO/hFRhYSuCKxW9SuZLYd/CJvZr1ozvL1d7NHO4dHZlQSOB1dbQ/i /N0cJxttO2dPr4zmNgobgNaXz5Juihehc3h6RiUZdFJARUywl3DuHZw9ozKauaIeMdvanyf6 2dnYixv2DL7X/MTqyLsY6oohPsmJDZIbdP+EhCLZ9xyobVXZsv2VwT08o6ySIlcfuaE09yba RlLaPdQv4TGv7HawFwaN9g9NKJIe1W99WpoUIFefg59XVFEzjy+aQEYrseKer624v3IzGH4r s4owmbhfl3E93BONdvT3iipq4Xd9BBm8k4ytuG3rpbhbQxOKa6XjWJd+P0y4/6SmuIzWyvJ7 7uKx8r9xV2ZwqNXPH0S6y1Xo4e6fWsbnz+Qx5ofnjybuQ1B3W/PjhECpiVlYbHY1QXrxyeME X/GlmKxaYgcEDXYxG5MwQUKPW8/w0PvVTAgSCSD9DParzBAMxlVaoScGk1TK4M/cF62/h/2q OATjK1MXBoOZypt3pIfNLA4JkSvthIktrZW8cDAxARHys2MDMcp4BjklNYp/4cvDJzBKYzAY p8CsxhbGpE8nRiYmGC+SQsI85aoMf1BXI3PYtePFg6ywyUzjnJxin3W2z+xArqRDE9wXiUlh MXdyaggQNCEYx+eFxQaGC/8pprujsShzsk5jMBiM793kp1guBEHQBAThX2TFTBojxskJE/us XhTlgGD8ZV5Y4ORVel13vt/UCWYoyFHTE6P8T1xJEXQUJQb7iAfS1cn5xoMmHlM86hMCAbcq MVFhoIVF/W/eeNLJ65U5fjkhgLhVxYlhPrLlwrMf1U6igQjGx/B5N6W+tqKyDYpl++mdDRnB csvby9kluYzV3fXGqjAYTNCdR0Xyb3H0c2kvEzH+Hoolw7Mb6t5Lp+nv7mwoDMb4iN1JvYJv JTdB3SLphcelPb2HwQib9YpMTa3hQRPjEKeq8O5N4Vg5ubjGlbHJogdZI+Nj9Kp712/Kxxnx 8OW7BCkYh3CPMpRH53pCdJHSSwDyhZ1cXOPKOeTGysr0mxi3ANewpy1dfQMQhH1455aZDqZ2 pCw9VFqxswsmrvwlWe5h3PMg61Avz6ByasM9mWH3DnFLaeZIbY77x0YaHoX6K4WoVLiPxqhL D8ZgXCYr6BWZpqDC93EoDfcwfu7SMk7OrkHZrViFZ56guSE/TqZ1v6i0vOLGuoJgjLcLxi+x tAyvZBz8FvpGh+sfhfj5y7SMwQQlPsMp1NRHbahNk2nZKyoiqZhGLYgN9PbA+EWlldXxoPHR YdyjkFsydcmOjqt7agWvR+EJKGjOz4+T2YUROQUNsg8zAbU+L01xuN1c3MIftgHWO+TbHwYj lIL4AC+ljYXBYDBuARERJZ2gfwyCaG0VadGSUU56Vk7ogfrYQ3V3g32Fk+QVGJlR0gn1zyAx yDgEYStSb92QGeekZ/jnLyqKozFOLu5BD9vwrEEIgoa76BRZA2GFMJS6NDpMqbgTECrtkqhm xbKcNlJxtFyNboEekSVt3QPCgexjk+ruYsT9uxWVWc+CxscgbHlKlDBmJ1ePoIdtBNETFcV2 nVw9gnKw1cUZubE+wpqxrwcHQVNdbuzk+wWD8UsqqyD2QFDvyGBddpCPvyioqMgS1uvBMYha XpZ6Q9qjMoLIP1kwCrEr8u6I3YadXDFBOWUF1wPexVBXTB+FVp12XXbD+tz0Sm/p6pNUNjw6 RK6I8w+ZZOl4BUVllbIg2SwxY8MD2OzAKD9xERd3THxlS/mjstQbGIyPu1d6JegT7bDezoHa u4HebtL6nFwxQTnlRLZoAgWjELs8Ny7EW7lltyDPqFJcz6DyVuC0PCuKxmCc3TBBORVEzns5 T08bSllSSqhCiMFh8SUtkj8C2c2EwluS+Rea4gpGBtnlsbEhwpXn4+GdUdXdLxqcIf5Ae16s r4fMrdEFg4nPa6V/1HcRZpVPQ9yHgZl1JOL+JC9PwMC8BaG4r5wPRwGJuC/3ggcMDMwfAQ61 qTXu+BENR4/4shmmS4KBeRf+eOI+DMysIxT3bQpmOw6YPx5Ccd+5AeK8TQgWivsyGX1gYGD+ MHQ9D/K3tTxpmUUWvfMBA/NfAizuw8AAPpfFItbhs68cM3B1CcnBYvF4ApXB588gtTjMnxQe j8ug4HHxJmp2ju6BxVgcnkCgsTmTHPbmsDtpzWVPgo8svxKSfLcCiyOSZN13YWBgPjFEjsF4 rIja0twQTcRhy+i4J8TZjg3mTwEs7sPATB+R6fHL2HA/p6Om91ksFovV9XpgGNZuYN6GyFO0 Kj4k4JyGVTGrmcLigL6+SWy7BRMTAz08Tq6rscc1O78KFovF4r4eGpL3MoWBgflkEO1uHktK jucpM9PLFkmk2Y4NBuYDA4v7MDCAWpOTeXXdojlf/f0fX3759TcIxMpl68wiSHT4bCbM22jB v7xutGj+ws/+9sUXX371LWLu4jUb7QoVkuEAAAB4XnzPUv3bb//9t79+/vW//vUtYuE2Lc2g asZM3GlhYGA+Io0t1X76P85dghAxd/Ha1aZJOVXEKZLjwcB8YGBxHwZm+kwIxgi3z+rv+vHr r7782+f/UlGZo6JyDH1fzgUXBmYyxiCoONpc/fd/ff3VZ3///FuV71VU1pwNCilmKpXkDw8m O+xct/LLz7784ouvvlOZ8+PPm9A5hS2TuzHDwMDMNiMQVBB+QXWXipRfT7j7ZLWBgRmkSYKB +UMAi/swMIBDI+DKs1KTkxJFpKdllr1ic2fo0wrzJ4TJ6qgvSU1OEy+d+6kZWZXt5EkMWKnt rRWFiYmSRZaSXSjjoAsDA/OpwWDS6p7cT0qV7O60rAdVJCrzndxpYGBmDizuw8BMn4kJQS+p urokN1vK81c0rpKlAgyMAgIIYpPqy0tklk7BCxx+EgPW4fExWtPTwiJJuYc5xa+YYgddGBiY Tw0BBLGItWVPZXZ3YTWh/a25t2Bg/oDA4j4MDAwMDAwMDAzMpwUs7sPAwMDAwMDAwMDAvBVY 3IeBgYGBgYGBgYH5tIDFfRgYGBgYGBgYGBiYtwKL+zAwMDAwMDAwMDCfFrC4DwMDAwMDAwMD AwPzVmBxHwYGBgYGBgYGBubTAhb3YWBgYGBgYGBgYGDeCizuw8DAwMDAwMDAwHxawOI+DAwM DAwMDAwMDMxbgcV9GBgYGBgYGBgYmE8LWNyHgYGBgYGBgYGBgXkrsLgPAwMDAwMDAwMD82kB i/swMDAwMDAwMDAwMG8FFvdnFR6b3UEl4kk0Fp/Ln+1gYGBgYGCmC4fNpJLxRDITvnt/BPgA dNLbiWQKg8GZ7VjeGz6ns5PWjiPSmRzep7p2OGwmlUwgkpld8PKeRWBx/4/BxPjEaC/g8rt7 B4fGZzsYGBgYGJjpMj4hGOjhckDP4ODobMfyp2BkqK8b8Lq6h6BxwWzH8n5MTAhG+7u6urpf 9w+PzXYwUzAuEAy85nJAzxC8vP8kwOL+rILLzQ26tGv5Ebuc9nrabAcDAwMDAzNdKgrjr+iu 3KJ7u6OGONux/PdDA+Ae5vBm3YuhIU9nO5b3hlyRkmS5b+5Wx9sVLe2zHcwUlOXeNtNd+7tu HLueNNux/ImBxf0/BgOdgldehjtUjX2yCxizHQwMDAwMzHThDvYm2W9bbXAtM6VptmP5U1Cd F2ZssPuEaQ7E/YP/gTM22IOLOHHiuMWViBLybAczBezergT0xhUGmJz0ltmOBeaj8CmJ+9js +35XdJAyHL9yJeDhKwC4M6iFC8CrbH8Li2NIJBKJRGkhbVMe103687mdRrzvra15EolEIpHq +leuxL+iMmfS1PvTlpXprrPim60mGcQa6kdtGWZ26Ghsfxx4WfOoGtLcJS6/crbDmWUIVbhE tKaaqnC3n0MH320EbN5sRzX7tJYkeDpqI9VOnrXPYLwiz3Y4MJNTkhNpqIpYpBpKr8TPdizv z7OIYNuzsl+/yPMenknV/4GWWp7Eul3TRmqcOufwgN083S8+KgC3r276RfWkt1fBfyCoDwvx cWH0tTNIjUNIh+gXLS1K19tLEmKN1v510ZUbpY2EjxRTaXoQ2lg8t6e9HjysfvPQP8kKPas6 Z7lqOBt+djWL/CHF/R4CrTTkEgqlhRKjqYe6lFBC5ffMrCIuofxuyDlxJRahN3PxU5Ssy73p YCEueC6ktJwww6bek/4OQa29xtJN2g7JD2gftWWY2WFiHKLnJHiYn0Gdv2Ad9wyC+mY7otlE MAbV3gqyNUShUCiUlrqm2Y1yJql3tqOafbo5xKK4iyhdTdTViJIi4myHAzM57IGeaONFCHWT xLj62Y7l/aFXNibYoGQ5bXrSv7yza/BDtwRYuPyYiygdDZRlVPkT0vQ/WJ7pq63+695TqRDr E79vDnT2N9121Nc+gbJyv/O0Uen62EB3s//evXv09AMKCB8pJhqpId4VhTqGQqFQqFM2ISHF zDeW7+zhRZ7/6Rt187S7Lz9SiDCzyyci7vMAwJdHXLI+e/KwNlqKU2hoUhkOgJnIfTwAcM8S Q0Kc0OhLp41V1/xD9fr9J62TlaQxqEUJLo4uaLTxiT1HDh3Y6lxBpH/cF/5pDfX5Cf7OoWn1 DCLro7YMMzt04mk1CdcdtXbOVzV0vJM72+HMMpQmUkG44zVbNNro2K6dqqoX3Z6Dzo8k7rMB qMq5l/e4tHEWxPOXDwuKHqc/n6rl9rq8+BuXNXX3rzlyk1aO+6ihwUybtldl96NdfaJL2PiO 2Y7lvWABUPnAStvo5KmjF2S+f/3i4wub36W+hgd5hU+yqihTXCbWPIoLMVE/hdygGs6qmq62 zQKgIjPEOzq+6N2C+qhQa6qyfW0MVJf8f6rOBdXKT0iYbVXPk4NsfTJL2yiTrx1uB8A+jE8t rZj8aMI7UPc0OTwAjb5ick5vyzdrzkdFFr556FsbShKj3f2in/GIjPdtm/yy6lny7exWPpX9 vlX92fgDivuvGTV371kd3qaBuWKNEeHqiwkpfsXumWFnuhnNjzMDMRgMBnNq8zp1y/NhL6Yo SajOjg3DYOyuXDTa/u/fzJKTa3jv3ZGZMNIzwShOColKfdzc1v1RW4aZHSYEELeqONHeCKm+ Z5PNfQgCsx3RbCIYh/C5GbcDMBhL8/MndqistMjAN/A/WvN0fGN1fkYdC4I+dtoJHr6zPj+y lNXVP2nLfd3M+oJAe6vDv5x0Tr1d95GDg5kmfaNDdTnBvkk5jQ2dsx3L+0LDPggM0D6y8wLG +pr4+9f7hkdqM793eMaVcbEd9QXRz1ivByZNOdPXRa/J87e5ilxw0jXrTsP066W2lacm3YhL a4H6Zh7UR2W4a4icE+d/9vAydUPbhMdK1wWjQ+yKuLi4jMwK4pQ3PNBcX12VXfqhTvZzOolF dzEYNwzmssbGgzqmhrFvfqzQO9xfkx3onZTb8or1vm2PDQ/icuIrmtrb4We3nzCfiLjPBqAw SHu/0QW3gIoPV2vL49YQre80Q6cQ96W0ZXlft9SaBXEf5s9IBwB3bHfrW8PivpTadLfLltof U9ynAxBno+PoG/yo4eM0KEsW2tXD1/j2yzcUIZUnZ9ru0oigw+I+zH8WHhlQQy5tP3rJNi7j gyy2jKuO7gHmca/eUKS99G6a3f6jkdMX9/9wNDQ+Dzj6P0d8JhP33w4TB0qtNc4HR6bUfNiw mNjqUuul+y1j3ibuf0jqs+6EnkVaPuE2/bEfg80Cf0Bxn/D8Hubytn3GJRD1A/78y7c6f9V9 anFfRH9Hc/21JQevpX9scR/mT0pV7g1XQ1jcl8KhNty/tmLltQcfU9yvzEkINdOJaoCgD344 +S1gH9bdMlvt3EDkTNmyYGSw9fphx7BsWNyH+Y8zUJzsZaG9+0okCep+/yddrZlVUVfWu72i 8oemKjI22NMSsN8+PG8m4v4fi2EIeuCrZWo7mbg/LUiJUaFBhs5PPmxYEASREs0w12zeJu5/ SIZ6wIPze7zvFRbC6Qc/YWZb3Oex2QwKAfsSh71hsUvnomlgAlYMgUJlsOWz5HA5LBoZi8WJ i+DbydROwO+aovIPKO7zODwGCY+XtownUBk8Pk/5Kp5EojK5AHRJOthBIYhibqd0dLIBAF18 0EklE/FYLBaLxeEmN9Rld9LJ7cKrbD6TRiYTRcWxBBqDzVWSQDkcFo0kGRwihUxn8Fi0djwO hyWQqIzOGSYc6uLzOql4UYxYLBaLw2IJFAZbMWsKp5NFaxeWaKezOrk8LquDRpDvLwAAAC6T Sm3HY8U94vKFHZyiR+wOuqjDorplqxKPeieDhMXhxFf5XHF/sVgihdwx/SOCHE4njYTF4bAE Cp1KJrfjsTg8nkRj81kMUcx4UcxyH2PTSfIx0juUR1k2KiwWiyPiSXg2P85GSdznsRgdZLxM dVh8O4XKmnR5s5nCoZMMDoVM66ARqCz+lJthangsVgeZIN+wXFV8Lo9FbcfhcNh2SgeDweqg EiR7EE8k0Tq4oEtYlsPspLVjcXgsgcZgMzsUglSaQRmmEve7AOAwqe3teCwWi8XhCQQam83l AwB4bMnsY/EkGm0GzwQ47E4aCVuHwwabalxxdL9bLNN1IqVDaeHweFwGBY+TzA0OTyAz+co7 8O3w2FwGCYfDYeNM0HaOZwPlWm6ndLAk9w0Zcf9pPUk0PcKBVXbgVJ5BQjuByuJ3zXgx8Fgd HWQ8FofHkpnszo4OSrt0RRIoNKbC7heOJBYnXPwsLp/D6qQShJNCpHQw5EaSx5FbOVgckURi cLsmC5LDpNFklg6eRCPTGEwqic7pknSez+N2UnCKNygmh61s/snn8DqpRJzMHmynMelEEr2T qVBauIBlVkM7mcagECmylrldfMChU9oJotv35Ia6XFYHhYwXXu3q7KCIBxKHxZLpbK7SbYLD ZlJJMu1S6AxxzAQSjTnzJ15dAHCYlHaZ+cMSKEzl/jKp7dhXz7GZpqq7L1p4Jz2WlCbRGawZ fmfw2NwOEg6HxcZcuGLrfC5YWhkWS2ynMGSXt0Tcf9bQTpIu78kMZuWXN/GNhrqiBSxdORQS hU4nkemcLt7Mb43SHsnsfQKdw1Gui8fqpMvsQTyJTK9qmEzcZ9Hf3t9OOpnwqgKbaXxY190v Kl92Y5Pone/5+PMt4n4XD3DoFKJ4eb/RULeLx+XQiUQCTjI4RDqT2k6id0iDFPa3KC7E88Tu i2ktJQ2SoSRgyUzOJFXzOJ10KgGLxWIJVGYn589u5vuHEfcnxqHRXsDlsFl59/1tTq68GMZi tbFYLBaLxeZxQf8oBE1ISwsgaLCHx+WypHT1jb7JkO4DivvDPa+75Fp+PTA8MslVDovbOzgm NvwTWeZy2CwWi8Xl8noGIUgAQdDIwMBrnrgqbtckhrpjY6N9gMVis7igd6h/YKCvS1ycA0Dv kFKnBRMTMoPD5rLA4OhwXy/gcVhsDq+7dxQan1D8zJsZGXgtjZHFYrE4vO4+xbOYgrGJQcDj sFksFrfrde/wxMTEaD/g8tgsFovL5feK+gtBgpHBwdccYX9B79DQ+NjYiLCDLBYHdPfJ92hs eETaYcWqREM7MTHcw+viiK9OTAjG+nsBjyPp/tg0XReFQ8fhsDi8rq7Xfa+54iAHhhRilvvY 2HB/H182xq5JTrlOTECSqETFXvcOlT1UEvcF46MjvVwuhyXLFMtbZuiEg8MFg4OA83pg8B3c GQXjEyOSJSptWFqVtAtcLr9ncGKkTzS/Qnivh8ZGRXMsXgwc0N3XP6QQpNIMyvAGcX98ZLC3 WzwsHNDXNzQOiWefzxEtTF7v6Nh017dkunMSQj3OafgVs1gUcWfYXH73oIJd5wQEDfV382W3 Au/14MA7aKATE9BQTzefwyqPLww4t9yquLJZ2jKL3d0/Ni6ZP4m4H/m8v1eyzJR3CgRBgrGJ kV7AZcvPYP/gyIwXg2BsdKSXy2WzWLyenr7+0YFu6S2Pzed1D8jfkEWOshzx4p+YmBjr7wI8 9mQjKZiYGOnvkl05LO7roaHRSVbE+OjIAGBJViSbw+P1jvR3d/UNDg3L7MGR/u5u+RsUX/kG BYkWcE+X3B7s6e7q6e3pVig9PioYkNkKbC4LDPQDTk+fvGXu2OBAT5ekNt4khrrjYyMDPVwW m8Xi9wz29Q8MSFYwiw96BpVuEzIjyWKxODx29+DYcF9PF4/DYnP53X2jkGCGd28IGhsZ6OmW uZ+w+d1T9rc6IsDa/PDxwMcsFlU0RKBrpmf2JwTQ0OtuPof1LOaR//nVNo9r26iSqWGzu/vH xiWzJxH3b1f2yS1vZYNZwZhgpKeLI1renDca6grGRkZ6ZCeQx+sd6OHxeweGh9/Bsl7SI9lF Bvr6lesSjAmGpUGy2Fw2v2toPMtbSdwfG5Lr7ySGupKqXoT7e7hoW6XJNM7m8l+/02KQ4y3i vvzy5r/RUHdssEemLIsDegB43dstDXJ0qK+Xz6ISsHGntzmEJSe/lOkNv6d3kqoFE4Lh/i4O l81i81+/HvxU/Yb/G5ltcR+Xl3f97AbE93MQX3/+v3//7POv/oUQs0rf7Eae/Nm/F8/S7Y4h ED+Ki6zYo2OSCqidU1T+AcV97LO2G8dWLJK2vGS1aRieilO+uvTIEYs7LyQ+Abjc3CC99QjE HAQCgUDqeSQWAQCYJJBifHzXrwgEAoFYsHD5EetJDHUL7rqePoBYsHD5EXQuOdL++OktCAQC gZizELEBHVpYr5Tkuao0zfYYAjFPGODWs6ccIwjZVsjF839GrD5yJTz+TccoJ4HZ3pJyafnO XyXzMQeB2GBwo6hAoeGqhDTbA8ISSIfs+9W4mpwAy/WI+T8gEAjkWa/7ReKCL2NMTQ8tQSAW /LIChc4lN9DzE5x19yMQiDm/IDbY3ChqkKs438NZdzNCilxVQlpLUkK1EAvmIRAIpL5PchG1 BpdleWDR/J8RCMQ2/dN+CsXfQGVJio0WYu48xAYDBxOdU8hViAW/rFSzyaM8CDExRi5BiP/5 ki73sXx3zVOyMR5y9ElWOmVJrcZmXhVFhUAgFmxZqeaWR4m4rCTuY3Ou+59eKVMdYtV+PbM0 MNlDivw7jjr7ZRo2MNBF+1uuM0ubySMNScMPH/qfXo9A/CDT8HqLdGlV1OrW9Cv7f/lpPuKQ gW9o+EP/K+sRP4lKL9uqgQ6sFivyz+8kWe9DzF2E2Ggb/iQywFFnn2yQvinFUwYxlbjPBqDy 9qX9B5cgEAjE3EWrNtoVPnlFBwC0PE4K1kTMn4tAIBDL1KzR9xqn3eHnj5OsNRHdg3U2AAAg AElEQVTfzUV8/fnfP//iy399KzPm2w39AxSjbMG/vG60aP4ycZmff914Mor64h2OvbYUv7yu ufCnOYh/fvbFF1/84yu5lg8aBGYAILkBScR9f1O1ExsRCAQCMXcxYqNdRIlSku627Cwf3d8Q CBVJZasPbrqaQWfO+D2ktmw/H92ViAUrECdvFaR4+50/IF2Ra4xsooub5IpXFCVc1RDe3A47 B6bVUiozUy1++3meCgKB2HEu8PoTuborM70tfkPMFUe5cPsxres1inKzsN7btlf3Sodmubrt GcvQGFMtl6dMyclfOq4hyXDBVsmsIOYhEBuNIksfK+cHp1Q2Jpvvnj93vrjhlXutbjts03RK iFEoXXE7QbbhHUZI3asRF7boxclY5rLawXN3o91rFgs39Mot2pMY6jY88DXSWYFYsHKLdgwz 1dvIaL+oOAKh7VpUU6fU48L4KxqSPfj7+fOuYY3J5jt/nDsfsUbDLjapSfEDb4MFwPMoo937 Fkt7s+b8rdgn8oGWR8df2Yv4/jvEvz//2/9+9vlXMntB1S04QynMN9NUUOOv/uPcHxD//Ozz L7787GvZ5f374QshmTIZ9iTifpDJYa0NwglcitjkEF3erDiWrZlpHtqS5f37Gw11WzO9PLRX SFeO5kVNIwcn9ZNOJeyWd8gt05hf7af241zprXHesg2bHJ5WKNfVmpnirr1OpmFtR5+s5wEo JXE/xxEp7u8yxKbJDHVbM1Lctdd9/x3i35/97R9ffvXPb2SGca2WQ3zy+2Uleou434kHFa76 O1YtQiAQCMQva3/XmdpQtxNfX+Gybceqn0SDs3ztZsc7FgfVnHzjU8RB5jgc0FyP+OafX3/5 9//97N/ff/u9uCu/rEWculMySdWt5clul9chVBCItZdiE0o+Vb/hj8UfRtwfZEFN3kY71yxV +eZfX33x9//57GsVFYSKioqKisqS/TsMY5sgaEBauhuCMl2RmzeqSNEKfvWm19Y/oLj/xAV9 TK5lq7ulDcpXf16jst07E8/qEv6/yDJ39RIVFRWVTZuRrpkQ1A1BUMOd+Kv7VFRUVFR+UFHZ qDuJoS6Z8irYQOWHJSobT/vlRNyLD9YSt7z6tJF/gVIi7i6BIN3lwMYNwjLLtswxzGh6fN3H YN8qlaVrd533aYJYMzyfXB9nJYpR3PDBC4F3FBruIgnSDfZtWKKiorLppJ1byYBg7GWMwfZ9 S1RUVDZtOeyWJewvBPHrM9OubBD297RfTgGDRGoI0ldRWaKiorL6zIVA+R6RnjQEaco0LVeV EMH42BPnfZobVFRUNm094pE1IegmxHjr712loqKybOs8o6wW2jRTHXWNj6U57V2/QWX1wZO6 toEW21V+mK+y8Yz/o6SHGSkWopjP+D8qlM9R3P44NlA2xs3aRzxKFOsWjEOE26KoVFRUfpir stHK/1FUtJK4P8BoqffYvnXlfEl9c+b9dOxGawVVOeB2Ym2AvorKYnHD27YZpKafW29xJ2Wy 0m+hv2O03kNvy4olMg2rHL8prUowDuFve+rtXamyeRvKIWO0Pkhvy15R6Z/n/bTX+iGpSdgN PnEo5ezu3xarrNYzDo4sqA04KxskyvMBBE1havEGcZ9em+Zmtl5Uy/9j7z3j2rrSdu+Z857z /uZ5piRPJoEQx7GTuCVx793GuIPpvfciUYVoovcOQvQOAiE6CNF77713RBPVyw1cwet8UEHN NjjJzCQn9ze8117l3ktb1n+tdV3H1QKwpfMQwo3XL8rtBMVPCwgICHx36paQb9/E8ju3CbPH 6usXabbXTp4W+PyzT//x1//65HOWZ/jjZTHdXDjP1ssNCMuijcVvsBS7Y5Wewi2k/cF48xKW 2RqKnRL44rPPP/nr//7bF3z8Wy3v+U4vdGSeab3BhPs2nlE+4oxSx9URQWXjHNWuzbxodVU+ /9MBZmVf7xGQDcts3LGPx9pMd6vrpbM/7RG4Y+0YHNNNMLwkILCH/kq5fxuZ3A8hS5ZXXqwR MVdOnBIQELigJOFZs/FqfSRKSVnwgICAwE9XJAxIkLp1DGvt1XpLlNLZ64xe7trz3TnLgtJ+ Hh/S5aEGoqrAif30kt+duXPDvS1GTzo0vbScRQCnNRJhKMj6gjp+HxlM4NZw33gFhyOdFa8f YTQscM4KYySH8XQy4ii9PLRGVL10bB+9vp+u7tUgRmgcswtmt8ydJhEdZBhTUuAuD0Pd5enO ZOdLAj/uEbhnmxsSQ0w2ZBa/p+KcVss1Ypo370lakcPXD+hljtf4OypcOyLww9l7xgH98OGO hWimm4kOyFNb2flB2Mg4hWO8g09TVC4e3SfA9z+f/P1vf/mvT75glr6kKu3D1c33x6t1WGKl K3xS4Iv/+fyTv/6fv7NO78PfH0JGTi7OMsoy4b6tR6iHKKPUCU3jsErO7/NnU08bneRP/UCb Doffa6j7bKqt0eniyUPf0Or7/pygoAvR/rawZ3xF1Udoy7x6BostdYVPsk6yE5oh4dx1PZt6 0uAoe/LQfkbDB+57l8wnYrjg/khBMMt4tXgY6j6dpFfF9+kn//jHf/3tnyyN/3hOBBU4AB+/ gj8nPgD3Kdl4jBRz4tx/r6EuJcsWI3V4KznaDupa1p46KCyjk8P5Qe6iAgJffvk///3///3T zz7jZxnNfQdPHlU/XX9UFyZz/Mp+gR9FzczT/lP9hn+P8e+G+9SxsY6KHEJ8CsFM5sRNMUlD OwIjsipqu1i0XodIRB8TTUVtQy9CPJ5WIhTnhdIRl9XAVvP4sQ1+Mbg/UZuS7KgpJmnkGBMf Q2s5GhftoCMuquGU0lA3AQB1ktqclYm+LihnpO5ELKrrmwaAjqyoo6MdZEKYrfyBS1p2IQmt A+MAgJVFMFhdSs4kEEJ8bHSlfrponMNtqDvW31KOd7HXOXfwmvitm+rmVh6hBAIhPirc9M6R uwjv0EIWmjmYS/Ay1lTSMfIiJOAJBAIhxM3CTP3mTZErB795oG8XQqzr3hHamO2rrQjSkUI4 +wbHMJ5HPIGAMZSXQVjHJjSwFKX0DzUUJEaHesruVzJFy2rqqcopq9sS4hIJBFttC5cAe/IQ vc7emprCdJyzHfLqUTMXC2lFWTk9a0wgITEm0lP9JjqqLLcHAACWZye64gyNVLX1rD0CmZPB 38pCR0vDPCCxByww+ND85GBnSWIa0VPvupKekqyhjeqD2+qo2PgIAsHDEm2Dtmct/N6gTA42 5IXjzK7wnzsuKGro5B7tH2Erf/P6vYtiBiinAALOLRT54LBxemEbTSR9dna8PM5QUkUbbe0Z ytJHDR0tM3Rgfg+TYXXlFfmait6h94pAIBBCfSNMJW6InNz7TyElVrhfFx3oaqNi6k7YihCs h5mOhIIGrq5pcJ5RjgpAUbSFjqm+DSZwq2FzucvHzwvuVkuemNk53KeOjLSXZxMIKYz6orAe djqSIhq49OahSQDA0vT8UFV+mrfBVUWFBzfUMCoadszPoJ+vs678bUX1oLrmoXlA6RuoTwwL 0b98RF5VQtgAbWO71UlLc21ZBUMn3zLA6xDJu+D+KgCU3uoYT9Urt0+fu2mVlVo7PjG7DACY nxhoTA80u/zfR+9qILAFDTuY35SJgfoSQmwKwVjyqqyatn0gS9JJle1suGm8qjLBTlNcRsc5 PjSWnp6YCDvEAxFN14ysxh3K9c+Pz3aUpKWmEDASCspq9wyxrC0XVHYMM98bAEzUpRL1f9h7 8vYlOQtbrzACgUCIiyJYK8noevpkN7Kop9Tm+jph1MzsCAQ88wkGutvqSAlrBGe0DL1L+Jxn UEfa20iBWDvJvaIaWlcVbNDOHswOOiMQKspKVrjkXsDYTUsZ768rTohI8ZC6rIBSlVO3VJG/ r2kfn4gnEGzQKFdrl8Je+ohqc4PNTOTVNO0JiUmM+e3taKIsch+TVd/D7OM8AIURZlpq8gb6 dlvJ8bUxULl+8vwxQeOiOdoC20xXeQlWV1TfNYDxVAiEOALBGiEjhbRPTm5mGdJYZXmkk/Z9 LYuExEhGwzgD4dMH/nFANTikkGVJsSYCZ2Wqom/nTSDQ+hjsYqZ7/+ipn/bfC2axzF1ZBJSW KnJWOoGAtUPo3twvEsptqDs70laV429uJbrv1F3Vc1JmFi5YAoGQEBHsIXlaSMXBI6dp646B zARXpJaqgak3ISmZQCAQgp1NTdSEbty/un+XqJFrRHpj38DOwPTIWG+8s+hVdaSvK8sUczaQ VjZ0cCWwZGeqt68un5AQTvCQvHBSTEbfcat4YUvn8My7m+AVc2Mz7cXElBSCtaiskoaIMev0 zius7hxm37mfpPvD1yfuXFawtPcJJxAIhNgIgpWClK5XAKmZLZ3zw0OtZdkEAoFAsBY9IG/8 TkPd/gwXG5SRhrkns1Ufaw25Sz8e/+G2SclCz04FYcbKS6Ld9eTNXPFJcYwKY8ODrRSuSKIj UipYXHKrwwKN9RQ00Q4EQjKjYXvtO6cvn+L/8307drg/2lRQkkMgRLr7o2W+PmAWyW2oOz88 2FKWHR9GcJc4f1sbYeHHksaskqb+rW+Dj4oPwP2VBUBpqcjLSicQAjG6Ord/FA7nbag73V6c 56dzWc4iICSa1rmYcKyl/PHTuw6Im0cwNxPQxhuIMdG9cVLMNQnHTGVaFqGsj9dqdG9lgoXK 7j/9+U9/+lohNKr0dyvbtM34zcD9jRfw0WBrRXEhyc8JoST0nRiKREomkUgkEqmwuqJ18hGE 9I1bDLtdQ+fYsCRaiXQSKcBWQxHhlJTctMy7/l8C7r9YpYzj9Q1UDdHeYTEkRoRiLPQQJp6E AhquWOzvjjdD6ypeQMSSKgZnn76go5g3z98+GmitiHGQVVSXR3nX9M9C+ApCCCanuqpIpPTc XH/d85eQHtyGus/WHo205Oa6it2QErl6S0NfwzaU1rKvsZKKqrZOHIuH4+ORqUqsvqgoMzlp +JgAoweKKjfOnhKRkHeMrWwbfAS5Dge8M96+3Zwhu7m7OFp4bY2YRMIFOCN0FMw9quEi08/w 1bO3sy1VpQUx1jJoAykZjL++6HU1i2hsLIkU7h1jZySeND7x8CWE8CWYnekszc3JcRC9bmWi rmdpLK2kaRxISk4nRTsi3bwCcYwBLTXgEx0RSpq2gSRSOq1lfGiMk6GoGBJXMzP2ZKuTi31V 9aXRvuZotfMyHgn68hJqSHdsMImUFBNtLikeWTMxti2D5FdvN2f6qkpDdIUlzxw5L2rimJub GmKCVJG+JqwpZ+JNys0h2csporHOOTQa8hbCmQa8mwPCQMsujJkdfIink6G6hGFy7RygN/tk 7nWFm5GMNq1XJBKJlJtD8kQi1G8cPXz1HCvcn2vrT3cVVHWMwacy6kvLyfa3UVNAuKSktrBO 76G2/EBHZW3jQBIhg95wlI2C8Mldf7/vG78Te0p6vFnfBAPN5UUFjIZzc7JDrFV1ES4+aa1z EMK3b+HTiYHmNKypucIpEQN3QTXH2KA4WllCdpY9UlJW2z4lrXUFvny6MdNYWeKso6gjKSSL NtM2Ye2ko66YhJRtJqV3kbsT74H76w9nGorDjaR2/5/LWjg/0vDIwnMI4dvNjcXeyhgjwQc3 rwiaE6qGHj/b7tbcl5sbM72VJaUkb3tTHeGriEASKYMx9qKKurY5uLWd9PnS66F4Zx0lpKWf Tyw9PSRSiAdKB4ny8+NakftAbG7Axd6OulJSqF0AUnivfGAEfqtlcn7b2NPnzLVMGtxXELl2 TAShY8+YZlhbRwtbbf/iCdprBEIIZ6e7U91vqDvGJcUz6srJzgq2UtFGuPqlt+6oi2/WHz3s KymL1JHQ1bx/V9tV0cyJREqjVRrlG4pSE5I2wTUsMEyPX268me6tKCmNtjRGIS/J2sTqi4mq Wnrh4kmk0MhIB1mZlMbZx09pnexPcBUT0rKMD2b0MjsrwwMhrmqFi2FbrRhszvW3klGRNMUm ptCTkxwTYqtw5er3P6r7k2nv283XL6ZznRwdnW1841heUFhfB31dVYxvHVxl5vH5wov+eEcZ PUuv4FBGwyQPA9Wbh44Ia6lEs3itzzT1JjmKS5q64YkEEolEIqUmRPgY3Lu276+3zNktc9fn pvsaSkmkrHSi3b2vlB24DXVfrgFKb1FapPYJSTHR89IoJTNfehbRqtoqOsoBJZPMJ/hoYKTY 30BC0tANH0kgkUik1PhwH0MROeUbp48/kFFzS6zpHH4Md7Lx/A2ELTk+SJQWCuW7lZ0oX3sz PTU2j9wXT15TmsuL80lRaEMF6fOChlgSKZNWury5Yegd36rvis03cKGnrbaEFGLjgxTdp4iN Sc5kTu/8wo7xtRfMx0KD+zL3rx9/gNRzDKeXCrSxQ9vpY8smWW0wXq+9XulvLC0sIJFCbNQM pN9pqAv6S/Kwxrc0nfEp9O+NpKhAG7kTJ/gOqfgV7vTDCtepa71xdupo58Ao1kkWaKOjZ2Jr R2BZ3Jtu6IrFSNzWtManJDAaTrNVeCB9bp/AbUV2uP+UOjpYRyJlp5OCNUTuGhlzG+q+fvZ6 pa+hpLAg0hyho3lT3pWl8cKy2q6Rx/DVNs+kvSM+APfXZqd66ktIpExiEuY2n5Izb0PdjRfP KNm2puZWFu5bX4IBVopSZw9fvq7p1g3BSwghfDI/MlBHyiQSMLePqKKcneJZRlPTNzj7mKvi x2ug3OeGwMG//emzixpa8X/4if/r4t8N9+kxDwDe9rYmyiqGzOMqzW4Xba9vYOCSUjAMGNoQ M6OdpGRndSkJU1xWSxc3iPhF4P5EXQ7WzlDFAIkraJ1bpLveUkdnmpODDKSUDYNxpK4JAMAS BTTZGxr7e8XVT4Dp+elygqsjNqGsomsGgJHJoWTDszqh5PoOrpabsgNQpy+icrnhPgAA9JWl +d79cvf52zp+2WVdMwCApbnxJryCpLSFY0gpkyx2J2HczRAGrkRmcqY7SnID9WVuH/7yINKf 3Dr0/vFzxExnEyncQt/QPbWtZ5zp87sEQFNeOMYW7eUaWT/CQiEBAItTg3V2ZyTuid6QR5gF RCc3A+oyAF15JcUlqXVsW/P6SogBwrtuCMtJGdh6EsvrJsAKdXqIHJhR0dMwAgB1dKox2U5W UssSF13etXXneHVJhC1aG6nkXNw2t8TiPbwIQG2IsoT0DSERHTMH1+SKuYUZAIZqi8uzUwuH wfbP9M+O9CbIfSclj3ZKa+yhtg+V2dz69PBt04iExhEwXNWboPOdZCipZggAQB1tbEg2lZVU swouqGCZduPVSeEYfW1DG5fikbmlVQAmOpP8A3V1FN0IpXML9HKU3snCAAeda4cFbinQ4f4i AE1kD4ydQ7A/64INmB5pL0x2sdLScEttZAKgWQDirQQlEWYRxImthovwWGfnADdCM6duykcF daSyMkr1xG5VL3ITQxV+AYBanIKo1A0heUf/lBbmZ3CotyERa6IlLuqaXNs7CgAAPcPdPrLf HhW+Z+QUW1HPnKPjVUV4jLmxkQqqpHN+mcs9+v2a++PtCZbOqlJXUCVtzHupI2NVcfonjqj6 EDO6d0ghAdie5v54R4ZvAFJN3jg0tXNhgt7w/PxUQ56/jraSkXNYwTs9cd8f29PcTzE4vOuS ogG2qIoGJhdnQEO8hZK6ZUByIaPdrjw3P4yTU2BRC8u26Pnh1qYkZ4ymhnN6SyUvMPe+mKjr TjU4dvSimLhLaGbz1pbxzpwMXxNdQwut0Fa2abYwBmqsZUXu3LypqGuO9SS2LCytANBZXVCc k9FAe1F0kixdTLX0LOKJLYCpwzHVXUcKNJEQFfdOaWwZAwCA5bnhIbKukY6JoUt6BktmB6vT I83kJS4JmtLg/nR7bWawBcLEI6O7f5IJBxcAaMgJtrJB+3nFNY4yX1B9aSkuyAun0YTZhQlG w2NFoRhrS5fEympW4puNMtBCClulM19ulLaC/CgnW2evyHdY5naRI/zl9ouGccN9AACYqCEk 6/wgcPCusENKVssYAGB5bnSIZKF6S8s6JJtpLtMZj3IyMTT2ziweATS5F0prfrqPluTN41/s Nw6t6OJV9/tiqic/FystJmrumdLdwvL0O3JwTsZqBpae6W2ATQ2FOgKqLaXuomxDi943I7cf 29Pcx+sf4b+gjAwuqaEdx1iggPpYM3lVK1xq8TuWpLLMzhlavxPutwZKKeuaaeK2fHsGKtNS /G0d3SOz+pandrbuOd5GxAVh7FCRJb3Lq8xbqVMj9bHWaENz/6SSpikAwDIAQ5VOCCtDa2t8 aStz9WKgsjrWUvvBpc//131bnpr741VtyahDB1HR3HCfFv8BmvsdOThfhR9FInjD/fHKhHjj y5+rpld00p8WdWq4PsbKw941LKuWw015J5r7lIFGUrKbhaWFhSu+uq7vZ5v5/sbjNwP3t6Kl JNJV/QSKACEvze3Hc63pqZYqYtpBhLbFOfrgXkM430J0xCBQtn45vPfc/3y4vz4310y0lRAz cEvJ65vb2mW63FwRgbEysjMJa6XSSMRsdk6srwq6kArhazjWRk5MiExPb12B8C2EjXh7D0+H pEauljc324Il7mB8uOE+hBC+3dwsRAmKCF24beJPZBDe2eZQPwxCVCuFyiAgD3uKizxUxXVw Ke1Lc+sQQvjq8cJcKdZB+9KpswpqDrlD7x8/R7x6sjlfHmxv4RVJrmDz+Z0dbUmOsLfSsavs pD5dZ7+JkmXrpXH9jDBC18ExsoY6/hDC1dGFdnJwOXX56Rao2dx4U2B6TVf8lqiWlVVwajkV Pn0NHw2UtdVXFo9C+HYTrrRk+digkHZOqS3MAcK12YXWZKyOhIpValb7PDsPoDQRvAxPn7mq o2tmHUnqGJ+DcH1loZsYXDWyPM/Ry/dGE87IRl5c2aOk9+3m8+UkDzmxm7dNrErG4OYGbHAy svazjGyFEL7d3FhuwfnYGBnaR6exTJi1me6WJFcdSWmrtLb2+XUI1x5PNJTpSWrbhCV0jM8x xg9HCnMCtMUv3jy1BfdnRyuTI9F2+qm9s4+YxytebW7MNhGw7hZewSmVLPizsSDYWvW0XhAV Lr+mN0ztzMI6ODrH1XZOPNzBgN8RbzffLDU5Gkvq6FoTW7b+eaoB74E8ffaqnn5w5RyjnbWN 1x0FwVamGo5e0VXjEEK4AWF+kKGc+FkZfZf0Cip8Ru/kNLUzKdBOWgmRntNE5SI679fcX3s0 WlKoc1hQNymBee/bDbjcHGesqqtn4932cVYZH9TcX3tEqSvFSGnoewQXDo4wGoZwqb8kxM/C 2AAdVb0AeXvivj+2rbkvIyl63zw2gznA6ca8QCcdbVviAnz8GkIIV0bKiyMs9RFpVfOPmadA 3m68XmrE490s3ENT03e63LP5CvYHoLUkbwghHXzK+phb9ZeHpoqCbHVl5L0qqznsvyfT4lzV zp57oKvvbBNd3z0FIFxemmtPC6sce7j2HMKV4TxysIq0nGtExfIUo5cbr18O5wc5GGta+yQw 16Qe9cck+ZupI8PDKqkP1+gLu88WJ9sSbHQunUbiyAWzEL4ELyklgTYo79ji2hHWqTQ91JAY ameLcK7uW1mnZ/bpxFq9zZ2jeu6ZzUOMhuEwOSPK1yMyM7OdZeYM5lT5qP33zZC6aUC79yWY pRRj/Tycwt9hmft6/UmewX4jT264DyGEGy+e9fvfkRISPK/u41tO/wSD3pQIaxMlFd8KCGnf Y8vtuSQ3DRlkeEYvoB2uevlwZrLA11rt7LEzKnpehSM86n5fbLxeH85H2pmYWPkWsy72LQ/W 5waiZOVUYqqpnIeaJonRThgJ1ZgutpMZHxvb1tyXEBd/YJmQ3cH4zFPqsv0c9PQd0xbgU15y LAPZ3gG674T7CzXR0egH3xpXTC3T3/tPF8bbkxy8XAJSake3t9DLjGcPx+uL7JCmAbmlo4us t1Lq0uI87ew842oX4fM3EEJAKYpPMNRV9MisfvjsMaPh9Za4APP7Z7+9J8dTc//NOuzzNVLB oLnhPjP+3Zr7L56s5OrsQXrzhvtv1kCfzw1RpI9r9lY9U7UpaTiPgMic6gXIKqizE839F6+e T9TF+wS52ntE5+T+Cz1Y/ojfBNxfBKAkQE3NyjqEyEmpZ2fHynDCp0yxeRncshy/CNxvCPC0 tJIzI3YzlXZosTwDunHG0qbWPhkNAABABSDDRdXawyejYal7tMlB7Iu/77tu5UBom6O2j9S6 3L7mkFDIfQT9g3A/xU9092FEcl4z83D6HACJGFV7d5/cDgAAWAFgKBGh5uQalMCenNnOwiJ7 wV2HjXx2Cve7UzP89H+4YR4diydyRiDG0ASJ8MqdBgsseIgG929d19TDFja8u2IAQF8JwVd4 12EJn5jaAR5n/cdqBwmIUzc9Yst6OK+Ol+SH2d+7ZJk+OctyiQb3b4lK6CMT3t/yB2J2pD9B 7pR9XEHeEACgb6QbK/eZhFtmTQMAYLKxP9fqlHRYYc0QAGCsNisZceGmR1VFLyd3GC/Bhtpr XrEqm5xdArNlCfb25rpe2QCwYaWlKdDloXVeXo8G91dnwHSIiZiGtpZ9EFe64yMjTS9ftksr K6XjayoARVEIExtzZw+WYuSq9ncpJ2wjqNOjHfW5xLRUZn3BEUF6l//6wDG7tpFehgb3L0or mFmkc8ymman+UvfL97xJVTULAICe4U4v2U/3KLvmZ3JqiTSVpQdqXrXOnp7nQuIfMtTtTE1z 0Tp5SSekZW54AQAA5nuLK/ykj/2A9Ctq27FmCQDbg/u1yc4oM2WrcM4jIEsAdOENxCztsKFN H9P2NuF+uvmlc/Z15T1sO3VzLOTdfHAxXYB2rCHFUMRQV9eYe+rEhRFNLknaZURV7HDlY6Ku O9ng2OdXTWJqqjkY61huRrTrPYWYQVY3FBrcv35VChmWxCMbKwBQUpB3LfLt8EIAACAASURB VB38grmuzo90FOjvVXbNiqtdAGBpdrg+Q+MwAleWzrUKOtJQnu1pEdGyMDwPQAc+yVP/6C2L hMRkrmEHWOoZm5gGkGfAMo2zjlWUx7rryJq64ZPj6WUyMnPLmiZW5jlOkNSEeztaq6E8WT9Y RdWdw+wLmazxYbiPPPP1XVxCwzAjkVQAqrHSel4hhGIAAFgGYDBGQ87ROzKF3cl2piUr20bo s4MmwTuG+9S2nHAPyQva2fPtXIi8PR7tjVJVjp1ZWGZRjf83wX2i+bXT9k01fWyyellmUq7+ 4e+69f1wvz/D2cnWAuGA23qAWaXlzYMzLCcGth01CWikvqiaJZFI4Jpk/lqiRi5huNp5sDIN KOl2ogbu4ZnVHBVM13WkWZz+3yLOv1O4P91elB+ge0/PHReZQM9LWhaR1NxHmedeRvnDUPej 43cH90caUv3R93VwY3CRExfMVPiauJrb+/LCK78A3Kc29KVYHLyGKx5Z4iSSSxUknKuCpG8N hE8hhLC7nBhqSvvzWWaA2uVTB+/ddq57/PbtxhLe08YL4140w9XyNuD+JVldG/ssVsLTXEQM NpAM7aBrFoHu7BgfRVXPcbjAIt3w9u3mDFFHWUJLcadw/wlls9rotgTKyjWKzBnJ8ZEeshc0 8R3T0+zKAJQsW2elB5eUY6sh5AVe6LG58abA9IKsjK5pbPMs9+W3G7Ddy8bMzSygivPqi8WN EZzWXXRgZhM7k6A0EZwRly6fdq8e5ol8th1NOJtgV6fwIQjhJoQFOA1Tc2RkMa1XA0E2jiEu NLi/8abd84GZWxi2mnNn64uFgaGgG3fQaZlNC/Dl1Hh9otZhdfzwNOezXcpPczQRYcL99crc MDvpywgsmZzJlXFfXV0HJ7/kraaG2rJCXeRMncjkdEaZ4sr69jn4MSrwEEL45u0mmGypqC5i tkkikx10hVR0jaJLtopNNeBtDK9dvBk6PrnKKhGyCeE02dEuwC0k5xmkw301EUVJW19Oq8yH r15mW4vYxOS0cO3G/JCh7uPJl6Xoe4JKVnHVHY8ghPDtxqvFQpShtIG+S+7HWnJ+EO7Pjrfj jQ/f8qucGuJ0+V7syvDzVlEwr4MLH/Gu3TbcR7hE+ZWtsN+aEGWs5NgJl55DCNd7s4K9ZK8r BJGTsrimjo+2vYOrPnGn+69fwf4AtIS0rH5IJgeJez693u8ppRSaWTbK1u/JtDg7hSvXNb1r 4QqP5bT1noxAPw0x01q4wHV1INbAy8HajPQMwrcQPu2MMPJ383Sv5yy28epFS7hDZnlL2wqE j0bXSo2uPjC394rlGnNSdIib4nX9lP6FOdoL6vnCi4F4ew0L58Co+K1iFa2ji5y5n2nqTHG5 oe6SmJLBKFZSUNgx8ezFu5YItwP3ZZWtTGPbWBI5WRsb4qZim0aXqHrYmhzio6HrPwEfsrxR N1+tTeOVpUR0tHYM99+8WptLUT1rE5qTxanfBMFwXTHye5mgnsox9tf3vwnu67rEB1Wust8a HWmm7tINed76frgP+ooLglGSZjhCejb9ARaWF9WOLD5/tfNX4/RwbYzRgevm8fg4rkmG97Rx NTYwLHmyvL4J1zsKgnwt1T0LGas19Nh4Dilhlnc19H+ncH/jxTNKFgbj4GofkLCVmrK27gke mkl/GOr+JuI3AffnAUi0VbN3987lYj5gaXqkzv6sUUBebD3XtV8E7ufZerq7a4Rzt7wIQF2o qqGHTywZANrG9igtI0/f2JzRhr5ktVP8n/5D4IG6R1ZTV0l3gMTX8pEZNdyM/YNwPztU7qJF wTjLVQ64PwdAIuamhjkmPp/j5qmmoWzUmRMo3E7hfm1kkuH5//WXTz7//As+HnHwrIipTzOY Y0FjNLiPDCiI/xBg7yvJCpW/ZFEw3sZrvKCvZDBU/pRFQQGPywONWZGWl1TDJqcHWVoGoDZE Genhn8A5/B3G9uF+X0lWqMIVi4LJdk6bBAAGsjIiHK+oJU9OL4C2YDcjlKxuVD3HshCYBSDB iqm5vzgJajFKZw989fdP/8kr3Xx8fHdsyURWPtQV46d3+/DW9X+elsXYpU9MzC7v3EN1eWG2 pSwRo3bos6/5tyr8/J98f/nzbRQn3H+AsgyM6uSsYma4L172pF1CMXkIANAz3Bko+6m4+9a9 W9mpT4+wuqoePj3LNSE/BPfBUHOWm8WlfXe8+iv6l1fAUld+tLvw3jOYorKP2bYPtgf3c8Kc 3cz0ohtYNsVv9ThI3skT61r4UY1vD+7TNPfr2LEvC9xfAKAmSP7Uha/+/o93TZ279n4ZbTvr 20RdNxF17DAqoqxrmPNadX6Kr7KgW/HMwlbSaXBfH4tL5rnQsQBATZCsvicuuYj74vQAiJWU tcPjCoYBmBjrJlod+QkVUVb4fp5dFRyle+b/+69PvviC5wvq0EUpq8BWsCXm31fa7ie292sB RoE9+47cQ6R01Q0vcljGDuZ4eSj8xPLBOnNdzil6dHJy8SGX7SkA24D7mdZCYhFUlqsccJ8C QCzqgqqlG4GTV0/UdKagfvoRFbljuN9XQwi1vqUTQV3gcWMljuCLvuXRyOZT+m+C+zTN/SZ2 wvxz4D4AoDYSZSzIMhf23X1gGF44Nj338OEOjVmzgnRvn/7L3z55xwfrkISNLbEPzA+DaguJ Oyi78GKuLnf28DLUZYz/Nw/3AQCUvqYkZYHT+xlJ+eoA31FDv7zGzrmFJc6q/oD7Hxm/O7jf XJIarC8R3MHx+xlCCCEl2z7a1968iFetPx/uj5X0xRgcxHT089gETmkmRrlImhMgfAghhLPt 6bFe8uYJr+Fil7+11MkvPzt5VCyg4dXmozwTfQsPw2huCLkduC/hE5POfpUD7jcXhbtonEEz urF1MxwMttXDIHYK91dHN5PEju3f9Y//+ZyfR+z5UuCyWfZoF/secUqWbaSvE5rnU2CJzY03 BaZiPjHpJJ564JsbsMDUxifWicfltY03bTgxvZDM8lb2lpsIka6yliks+vUfF9uE+5sbbwpM HvjEZuZxrdXAtelXrbYPdGMzy8fhUmNXKubHw/Y5wwtcs6qpgFVzfyojyVr4u7/845+80s3P z39W1sa1iuXulfZeotFFfv5v6Ne/2H9GSC56oWvmOU970vfG5sbrlUfUAi+xYxf28rG0+enf /3JOmBPuu2NE5Ow74SIXkW4Mssa5u0YMQwbcN0Gz3UuLZ69ftmBFdEJzKts4L30I7sO1Ny/b omV+VDOPCal/8QZuvnn1KEvvuIKJp0/pPM8bthEfhPtDA+1RUkcciseWuDu1VJ+Q46Ygmwpn uIUlPhjbhvt2oaSYdo5bWeH+ZH0CWu27v/z1n/xf8Jw65xTEPGp21jca3NfEmHoWcGHlpedr eORdpwRSF9va22RaXKi/Eqb0HTVO1sWFuilh0iDkkap6/7ggT6WoEQg3IOxPRWlgTD2j38+z F/uexYoc3CvwyWc8X1B7d++9aVk4vSXm/+YFLLEyEDnBKCDAz39U2omYOfCEwzL2GaWz2fnC qUO76QX5DuzereTe1N/37AVPVZztwH1MWD77VQ64X5fj66Bzjfnn1s2w399MHYPaMdx/+uJZ o98tjbD8Wh6dWuh5hpe95VSW38P++v43wX2bsMIE9m/FnwP3IYRL/TXJSvw/fcv8sjr+3VX7 5K7JmR3z/f7uMlvhP//ly8+/4PnJ+vbMvXsB/fPgJZxIiXTESKnHdkPIPpteQpjrzaW5zxj/ bx7u06IpWEP3CktefpTT8cppffjsBbt3+h9w/zcRf8B9AH4ZuP8QgKUmrHVYeKx/Vl62+dEv 7goe5zupphOAzcgtsLksFthX3sdNCP9T4b6DqoB0cF1L1wCPGBoZm5pZAqssGPkPuM/o48fC fWEDhGNCCa90DwwMjE0vUFkn5vLc7OTY8Nb1ojh7FeV74mJ+LdPvQOPvjq48f12tu7duWJNa OnsZFVbUljg/+ETM5T8I7q8sdZDqnYW/OIMJKuseBQ0lCS6K+xR8+ib7l3dI7Ri9/r3A/XtI Y1e/0ndOnVleFgfvi98E3LfV2KMQ2rY1Y9lfUOOU2SWwtc61srg8Oz44OMgoUF5dZCvz9W55 x9JMdsvYlYWZmQmWD1ZlTLSV0uWT0piy+b6PkuX5A+6/K34luL80R5kaZZkLmV4BmlI/XUbH LSzt0Jg1K0hXX1McEz4w0Mdzko1Tpqkr/4/D/dWVpfmJwZEhRlKaKwYCJa6ckNcNzq3irOoP uP+R8Qfcp8e/FO6/WWjIL3Q3d+iFNUFysmpX9xy+InVEwbVnszZA2gFLwNVzu+D9p8L9ZPFj Cp6+xIZ53rH06PlrDtnfP+A+hD8D7rujbz/wLJmfn+CV7sXVx09YUdfGq9frYHHrem9beQj6 zDd3rHMLe3eag9XZPqL71S+v6scklPQzKpydn8e7yBiY/AfB/c23b9aepemqyJuq+paOw9VX L9ItTio4RRfXb99KgqvXvwu472J5XxJVMt/zjqmz8mSHTqy/CbifIHVQ1jskq5nXmKnz1OVH z99srXO9fQtfPALLC4wC0/PzSZ6qtxUVnb3ZLWM337x6+XhxkcooONIynmsueuIWIqi04mNl ef6A+zzjV4L7G69frq3OLzCfYHflMFbm+I9qmLzWd5vC8oz+7jI/6U8lfRu7W3hOssXl5aev Nzbf/j8O918+ffhwiSUvuS7OyopX5f3y2f+r9gfc/03EbwLub8nypHJCwbnZsXKcyK8ty2Mt h0rlkuWZBd04ky1ZHgAAmE3D+Pk6SZk5OQl9c9k2A3n/qqqaurSZh/vdiwapY408hFN+Ptxf AWAw0UDNyTUokUuWp9jho2R5KIXkSGuh4+apYzPb1Hr5xeA+TZbnlkdsWQ+ncstEaX64wztk ef6lcJ8my3PLo7qil9PZcLwEG2qvxZDlKU2wt0fxkOWhsMvyzANKpoucAsouMp0Lpm6372U4 HFrzgmRYzTR1Z26Lg8mBzjaahkHFHdNLW5uTe7kAPV2WR0vf1auCs/Wp/lKPK/e8c6uq6bI8 vrKfnjMNKyvhfIRNZelYravWWR8hywMAmO8dLvdVOPajrn9xYnII1lLpuAi2eWaBS75/m7FN WR7zd8nyJBmIWdphQ35NWZ4Pwf0VACglTtKGaCebzI+cOjwb7k42Ova5vFtBM+eS5vi7ZXne CfdXAKAQEPcsHfyCmzmvzY90FhowZXkWp/qrcXc+F7eMiat5rw3wVF5mkNWds1ZZsws7sgtm NksdKas0u3RVJyQgt+99Bakj7ZkBLvJXr3k01A5Qua//bLi/DMAAXZaHvYaZlqxsm5sfJcsz 35YT7iF5UTuHhyxPRzzaG6Wm9J8hy/NrwH3OmOqpiHQ0uH9JK2ehk+c3zjtjNNdN31JLD1Px XuOWlWlASbMVNXAPz+KS5anvSP89y/LwiKV50F/hKXdJ1z44gn3Mf8D9j47fHdwfqU/1R9/X CR6HS5y/+Wcr/UzczO19fi1Znvq+FPTB68HFI0ucmr3LlSScq6KkTzVdlge+HChqD9O9Hlzt Kn5M2chBwcDO9v7x67gqV/Gbdv6pqTx+Sv8icB90Zcf4KKp6ccnyzKbqqHyELM8r6ua0j8pV U5/k+u1zpV8G7jNkeVCBvGV5tHnL8vxL4f7bjTdt75HlwQltyfLUJWjyluUpYJfl6SqPdkWK IkIn4MoOSSyEEMKX64vtvRGyt8W9IooGdybC8rinr8RX6LYFsWKU+oi5+MQT0E814DHmt2+o k+Es2ydhE8KZfE5ZHlU9VR88J8d5+OpljrWI9cfI8kAI327AxcJgQ2ktfZeAkoHBeLGL95wi CvofvaP4NmKbsjy3/d8hy+OjqoD6lWV5PgT31ydLwsMNJe+ET0w95F47/Kigy/LoaVsTONVx nk+vD9BkeUY4ZXneB/dpsjzipnU8ZHkG4wy8HKxNc+myPOXuSqZ6+ibZ70WAL2fWR71lz5tg s1q5hGe2E5sQLowno22MLSQDu99X8M3a68XONKSgmn1MWD0PX4dfAu4/bE0O9lHX9Z/kkuVJ UpYS0f0oWZ7ZFJV3yvKUGO77z5Hl+cXhPme8ePx8uNJd9JghjpSzM/OJp5TWLC/BQ8bZlPal 9xZc68gP8nmHLE+45V3N36ssD+9YHS0PsjBVkbNoYHuCf8D930T8JuD+CgDDNaHm9mb2lhF1 Iyy7aKcH6opDNWUljYMym381Q92a7EA7MwNLp6KRmS0byen5ySKCsawmEheUy+L72hUa5KF/ 5eIDsf0XjfPGMrzVDFRv7LumIHVOGdswOcADQ/58uA8AAF14G3czCzP/whbmCsRwfU2clfyd w18eRPrtFO6D4f6yWJyEtDQ6LKljiA0tTdSWpsSGhaUVj7CoXvyCcJ86MtWQhJGRQoXk5LHJ rXTXEzxcdZCKjoW8DHX/pXCfOtJQjzeVkUKF5Laz9bGLnOyO0jW0diqkGeqOd+D9Aw0N1cKL 26lLTBvY6WY8DiF06qvbDEPdFQCGqnGmGH2koWdG8QgrS6LMTpUlOTvE5nTQENgKdXq4ICg+ t7aqh42RDBcGBKLkL6riW3YKu9uCXYxQ8nrRrcyP1XBdU4arkf6Dn/4ibMsJ969JCd1VcIpP bWUa6gJKX2VRqL6OZnhq0zCLoe5hYWET5/gqFlfUiY6S8FBnjLFTUSd1p4a6tJifH63M0zt2 X81ETFhKTVJBHNcys/DRBsIzAMRbikghUFGpTM3+rrzsaG93XEIafYDj7ek+/maGam4lndRl 5grN4sxoE94AoWboHJpf/7GGula6CDGrNGbah2qz04PcXb3TqheWaI92G3AfAADGq7De1nrq xt4RJaOLLIcYFmbGG/GOfrGk4pYdOupO1HUTDI7tuiiu5hZe3MLiZ9BZm+DnaeFiTmyhLnEZ 6r4T7gMAQGcO2tnM2sKjpJVFv35+uK020VlaTNST0NA8CgAAC9MDDfFSipJKph45JWzUfain Pj3K2cM3u3dgchGAwe78yEBJOQnLSGL3CNvwxqsL8dERkVmlo4C2VjVUk1WYgWe3kJ2fGyoj 6x69bRQbUki7exmAoSp8bG5+TSPbAx1qyfazu3vtQXBH4wgPP9afDfcBAKAjFuVkam0VXNrG TM5gdVkkSvrW8c8/ylB3spucE6AgJhFFbBplTc54Fd7bSs/A0iO19Vc31EVpGUrZZTJHNFid mYr1cPdLr11eoRmV/NJwnwpAQ25ICrmsjW3iUNpKQu21BO+YVS707NCZdaAyKMxBWUHTL7p6 eWzr3mUAhioTA6ITsnOapgBYAmCwwgFhZeXunNM0yhT3p7Q1p7tZiF/+4mca6t7VtvDLY5rT jlcmJmB9/GNyysbYTs7tKH4huD/YVVOQ7J9Zv7q6lZulWTBEchQRQjhHJrKvmnXkRHrJnLzk VtM4RCs+OTVcFI/BOIXmV7RznKmgDDblpXha29hYeyTX1vf/Yaj7O4P7j+Za0lJsdCRsK5rn nrACorFSDzdzlK1vdgtPqPnz4f7a3GwTwVpMApPa0jrH1nJbspubsZ1xcMs80/d1tXmoyPKS hK7InlMG7mmxWcR0s9Ofi+veOibtElnSzAND/iJwH652FxW6a0oapJVMA/qGzPXVzR6iO+L6 6XMKqjuF+3D97WZ3oZm+ubGHZ34bGyBam13syQ91CS3oW+E4yfALwf1NuNyc6W1jYx8QzuaS uro6VUTUl1S3IGa2cRvq/mvh/ubGchPW2wbjgM1j7+PoRGGovpSURWprG91Qt75EV1LXLy17 kNHnt5twuaUiwlj18i0WQ91HM40pyRaqUsjw9K4V6lZiNyEcbcmNT00qLGM8hkeD5XUVRWxG oBCuzfd1+l+/pYSNqxjf2T7ypcZOIuanIw4Fo4v07K2tbHSnhAdq3jsuocoJ9+2RZw5fNXAL q16aZOR6c+P1aJFLgENAMLF9DEI63EfKip+TNXDLrFpgGOrCtcfUltJgA3P7zMKOnRrq0nMH 4VJ/rJGdjuxlFYzN9cO3HfOLBn7OM28kR1qrXkfi+hkcamVkuirexc0d30DzfX32aKq22FpK E5OR00llXdGYaY6PcjZBoCIqmY7BO4qhvCY/1V23gslTq7S3wtrydBfRNcATX9BDoe0R3x7c h8+m62sS0ZIyRt4ZPcMLbMh9pik7J5UQX7FDR10a3JeRFLpp6Bxf0b+1H3llebSYgESYxFQ3 TbGn/QNwHy4PkUg4XVmlzMq5J8y34Oab18tNBE9LfWvvOOb0nm4ICLBSktXyz+yHLEcOnr1+ 1VkYGhCdWls/+gTCZ6+ft+UbapuaevuVdLENb216roMc5hFZNPSIloxnS1Pd6Z457auUrdfv JoTL/TFIGxMLlWjm6+3RdGdNRVpO9QJc3zICffZqvTVB8bquIz6+nYcf6y8B9+FyWw7JTVfe NKtq8Sm9j88Wn7clOmhfPP6xhrpDeQZ2pj6+iV2TLP/+bLqzOtFVXk4xqopK+ZUNdWt91Pfc DyuafUT7pD9bnOxIcfXzTCrqn1mAEP4qcH96qKGKjK8agHBr4eLlw/XRfFvBS+YRhcW8zl68 J54udDcnSGuo2vqm9vcssF4BlI6ivPiYmNrFx8/fQAimCuPjzYxUY2p7Hz9/zmj3xUQ+3lr0 6nf3f5ahrqOZuDKW4dwLn1E6WrNC3L1iCkeevHtZ8MPxS8D9py/Xu8hB2Q2Ds+y56S30tTCU 1XTrh4Bl/ejFk9VcnROqtqGR9fTnD+FwfVp0WEhqcs0Ue80vXz2fbEgMCPF09okj5XX9Ahbx f8Q2498N96cHhpsKicREIhEle+KWuJSxA9O0rrCpdYBF92QwN8XbAamN8SYSmS6KEQHuaJU7 mtiqOsYvwJUl6lBtVn4WkUgkEkPdwnQvfnJBz8I9lEgkEonZGdm13QtLVAAAoM6MdTbkEtNT iUQiMcxWTUf84iEF76j4ZCKRSMwsLq7vn2aAiYkaQrIXUsLIO27LvzEiLhqtKqTphq+vY9vc XproqSq059iPR8ySRyjj9T5O2lf4954/fNOnfHyW3sWlmYWRhqLM9HQikUgM88Noi+8/JG4X FRBLJBKJ6aSS4o7pxeVVAMYHWiuSXTEGVw5JOkaHFnR1jy0A6iS1Oz8rw1zmhryqhnN0SX3H NFheBWAwN9nJQk/JxI5ITKL7Stq7IUXPigjuP2i0Y1keAMBY62iylYyQgoEXNpDVSTDQ2kJH S83UL7GbBmFnx7pqK7OJSbFh3nL7hbUdTXxo5VKJRFJV98Q4HeKuADDUVpafRySGuNjoX/1B 0jE6II5WMjszp65ncZm5LXZ5dqIrFmmItrX2DGdp2M3eGInU90/sZuyhpo6OdlTmEpNSiV76 gsKqWqaOzLI5VQ094ztBApTJoUZyZCjqyj55E0fXtIaG/paRbn+5zy5r2XiFVbV3dDT2Z5md umbo6kWsah+cALOz4+WxSAlzW38vtj4aGiGsDQLIPUxQ3pVXFIgWlTJ2jsfThxuDi3ZQExU+ +f0/TwrJmXoUVtYNg+VVAAaykzyMNJV0jX2I+C0Dx/DYSFPl6/fNgqqLegAAYHGyvxZz8rYC UtuBtWGiv52hCdLALLFnbqeweyAbb22sLWOAZs4cfztXvXunrxz98n+flsFgYxt6BuYAA+7L KAmdFtFT0bAnJiYxuujnYqUpbps53UWnoj3Dff6yJwXFrwgp62PstoxeA93QZpboQHwPY2GA OjrSXpFLJKYSiURioI2SiPiVe0o+xEQCkUgkZpU0NA5wPUPqOCi0kL93bPfXJ4SkHLeq+piY B6AwUv+ukrSBphOjj7aaOnJ37yAdfMsAXcxmvKoy3kNH2sQ1MSmOUSohOtxG6ZqOR0pmw8eh fQBqI/y0le6LaaEZbzNPCx21e3dlVH2z5hYmwexoR00e1hIjfeQCIt47taVjeAaA+YW5zuqM NGfJK8oaumaxpaWdM8srDwEYqExwtdVUljbxwSdtTZ2E6DAbxatSZsH40vduTueOibruNOSx c/fEz0oaWrh4bs0yV1uEjZV1UhljBZE60tFekU3ERxG9pC/f09E199v6CFb39E6wruDU5Pg4 2aihHIhb9qTRWHc7A7l7mKz6HuYO83kACiJM5XQ1LNl8bYl+Pk46crcV1XCNrcPzAAAw0jCQ YCF6VR7hG8zmJRxgaaapqWURlNxLXySrCjawlL1424LIYr4bHRthZyB8zzKigZEbKgA1WGlB NUV9dmtiPx8nY3Uxy+DGhWH6iZh56kxHVXpaJpFIJBJxDkitK1+dM4j3jaQNuyivYXh5ZRWA 2ZH2alIA2kb62Dlkom9aS+fwDFikzA1V5qd56V26q6aP9i6qbhgGqw8B6M+Ix5jrq5tvJcfP xtFA5Mx9oX37TXYuywMAGB7rTnK8pmjtF8ziLUsMsFTVRLm6JG8doKCOtLdVZBMTI4meUhdP issaODPL59T09k187KmY6jAvDQVhSR0Lxog8zDVV792X1wzIWVymgNmR9urcAHNr6ePnkHi/ 9NaukVkA5qgzHVVpqY5iF5W1EOi48rKumdXVhwCM9jaUFjB6hRE7KCKtpurM+LuYdi8AYAqA GLNzIipqls4sQyaGuLgaGytoBeYsLu9s4z4AALTX5bhbiArLWSSFxjBrTCQSPS2UZTTRwaFF jCdTHRpgYaKKdPAlElO22pW4evEo/59Pyzv7R9V0dU2ClYVZSis5PyeNSCQSozwCzMW/3iVu 5BkcSSQSiRlZpPLmydUtk+fFKdAR4SRxW1Ydbcp4Kv6GUgpi4ko2oSm9YGUHcH8FAEpPFbkg g0gkEhPD/T0lvz4hbox0iSQSOVxw5+an2ytTU2nTG2urp3n1m7OIpIAo2pwozm8cWaWvKlTk 4MzFv7mHTCZEbeUmmuihpyxt6U6s4FjPGKpNjTAV3Hcd6YOlFceGVA5C7wAAIABJREFUBemI HLtzBxGdWsmx96K3MsFCZfef/vynP32tEBpV+oEViN99/Gbg/qs1ONdWW1FMJvu7IJWFvhdH k8kpNGe28sbaAZYtc49HpqvC9USMPOMIBFbPSGNpU/eYpMatkmCqp7uGcdlJ4o648h0Df8bf jd2UZQAhhG8gfDzVVlVTRCaTyZkJIViZXSdlbCwDCGQymVxQSq4cmnv6gvbj9MUqZSxRT9/K yyectWVvR0NTa/vkfDZtlqmJPpzywV2HvlJ0wNeNzNd2xynw7/r6q6NmgVld9NWHt2/hs6nh tppSMplMzszLC9S/cFJGw9KWYdtX3j03/+gVhGtrj0Zb8/LcxS9oGFk5ZbW3TT2Db9/CpYHu xjBnC737F5FYclXL3NNHryB8PDJZitO7ooKJwdNNI1MT8hyVpdRuHbuotWNZHlon26KDTJDq ho4+rE6CyWGxzoYPRPSDqmdGn0AIXz5/MjtUSS4tIMdiZJGaipLOzKKlte0jU1sIBixNdTWS yXmkXEexcxpGVnZbNoWNPTMrrKxpqSExwdda0y6cpeHYhCiMyjWDkMqZMRoSe/N889Fga2Vp ETnWD41UvixlQSYTaWWLa6vbKY8h3LZcy6u3m7P91eWhejJ6yoqG8dVVw+DZizychoaasKFn ZV3b7MZ6T5CNmaWmYURl3eAcfPsazjQkuvpaW7H3MSASg7yOSKqaBXQQ+GTudYUrUsPMwjeC Ptw8EjkMY65z9+xPp386KGWZX1A29mRlDcLHQxPlAXoPRA1dEyJTmDXmkcle9gZqRujwOAYf nMqwdkFIXUFEsD4WYnyEo+p1ZGhV4xgPBPm+eDw0XhCod1rSLAYfzagr10FJQvr8/q/PXHuA 8qnpGH4MX25ACKca8D4mZ86I6F1TsI3DMcxJSbk5XkgJl6hCBqPagDA/yFpH6uwtFSUtkyAy kW70mpwU7WEijoyomxt/Sn+CG2CwpaKkiEwmk5PjsBYye/bK2EViU8hkMrmgrKZ6+PEzbqXz QWKCg+h33x/Ys1vCp5Qyzrmhfkcx2Jphh753644FOTGVTCaTyeGeIQjRU2ISlpnTdJz3fOn1 ULyTlqWzfySLHSsZZ6ePxrj4FH3sNtTZlp5o9LUf7iKiE2No2YkJQYmdlhSxDKvsHYMv1x9N 95dmReudljOwM45qbhhahnATwsWJzvpke1PDB9cVcAVZbdSFx68gfLQ4WhynJ6po6BYQlUJm 7aStnr6RpVXi9rfdQggZcB+hLHROykjBzJlMZtjLxsSFOWnc8s6lrCxCCCF8s/7o4UBleXEB OcbKxEDruqwrs+nius7OaVb+OjPdRXS9oe6UQEhklCHlZodaK2vZhUeXsh7kGGjOccfIK6q7 kAlMX1tySk6WPUJMSsshLZ22nrbxCraE+yAQmmaufqxjTgqJdESKSxqHNC5OPoUQwsW+qniJ v9w1jmAx3yWRyaEeplpWTjH4rdxM1sbamQoKKgaRCdms7ToYiCK8k1oYy3ibEC5OdNRXk8lk MjknM83+/lcP1NCmWDKZTCbnF5CbJuZW1yF8uQ4ofSXpUTonZA0cTaNbGoeX4dsN+HSivzk1 0FhfRVDOuqCocuLZw3UIH/WP5GP1hTRsE1PoySHEZNoriqoKHT2ns3NZHgjhGwibsx0dnFFs yUkKdnMwR8j41M0/pIPhN2tgdaCyrDifHGNhpChz4YYRjkzOpj/Brq7pj/Unn25sDze/fuS+ YXwS7b2HjwwyEzsrIWIdUTswDl+uAUpfcVqU9nEZAyfTmJam4RVaYsfb6/AYI6SYkHJIUW7H wtKT1xA+fbI81EImF5LJZDI5DKOufffYNSsynmYmXkm7lxZ12d4ohWPyVixO4+S0hExfY0Vp p4jagR2ucUEIwfOnhSFaogbGvu6s73lyNM7VFKllZpY6ufz0NYQQTjd0JdqLS6E8CenErXYN FKUv/PDlmRvSZr7VTZ1U+PINXJ/r62ssIZPJ5NxMcojmA0EZSU3nSDKZTM4nkyvaxpeWWZc0 FqqLfI00hWWVceSUbDKZTMb72dso3ReSMQtpWaXs7OGsr1L6OsoYA0A/kJeRumkSSf97ywV3 E8KF8fa6KjKZTCZnpxFs7/AJq1ujcGQymUwuKCI3T1Lpk4f6ZCVGZ88tfRtfHFtuXF1MrJF2 hHr2VaLX64+agmVk5TX1rWnFs8lkWxNF+QfyLg4pPexdfbwGyn1uCBz8258+u6ihFc91yuuP +NXi3w33m5IzrW7xdqy7be3CsRWUq/DeM8L3vJvGZ7ckIqiTw2n6P177kWeNP+07bBAyQhkC AIDhtsIA1Cm+PQK8Ch64L2wc38yiwzNYnYmT5Pv+662Wv/3hvjl5vINTdb0rPwipKnj9CCJ9 hEIFoAjvpHTrJ0HGnwAAACitI7mouwf27OHV8t6zIve9myfnlun3Mv79iFpQcOEIGKwaxEke +o7WjwNnRUy9mca2w/n5/iqn+PjoAzooLKJhQ8pGnfgIzX1aLFFAkyfi9qkDbB28o+qeUsI6 3kCEymE+rviKj++0Oq6UQT/mAUh1lbxyjseIDx84hgybmOFQFSlylVRgK31E2CQ0kVV5aYhM 9lU+xcf3JXeVR9RNw4q5VZreHY2VqRYSfHy7aJkTMTVLLB7rw+oc/PYQH98FNU/vzNahLNNb 33+zh++OmiexFAAA5gAgukhcPsva7lENHu0OVPRhJQ5+u4s53oMntMImYowkLp/l4zt8U8Uw A8zS9wQ3VhDRzG7w8fHx8X37/U8PLIummadSFqeGGt2Fbp3knDsHH6DM8TsZMWs0xBPRQqx1 iZl7F/QEauzfe4jv6ANUBL4HMOC+gWegD5bkY3KSbzcj799e4ND67xnuC5E9iU4oDvW2lWOp l++iupdvGUu7Q3m53ooneT5BPr6DD1DoJO4RLQBQiZU7ff6KvJxXGdfVnUdntK/uLRYH1bsa Pmmc9faXdwWIf7/nK2ahr/YdPW1VXNnzswQmhki+noosLV/UUPcvZ3aL5Ku7dZFuits30hWg +d3ug/S0S4j7t8wy1nL6ypICxPl2b/WRb9f+42esSj6mkxN13VlWxyTCywhu3tqsyTkqio4m sOzkH8z1ZrOfZYmjWhHRZexUbjA3y0PhJB/flm3z0TtnTbNmF7gtATpzvLTYKz50UcoqoIXt tBBYmAANLtqCx/extXxPyz+znKVUXYyl6Q3O7u09fF4uepZlP/ICAA0RWtdv7uMoyOXNC3oH 2/009n59gLNK2ojunjejjagjx0tLnjmEe07+me1gsqEn1ejq7q++oZfVMstirE4N5mS6y59g JueQuLSeTXoK6seP0dynDWgMNLhoXT/GNqB7ToFZbCYDg9me7vK8n+AxnajY8h2e+WCv2VWO 5Wv4srYOlqnn1ZHtqbl18b5zUHYHAL0DrT6qu7+iJfa7yzLS2NbF5VUAyJEoSUGu7rHfCwCg AJBsd/fcKc4SV+7pYLN5eWZsLyZHOwnOl3cd2c3erEtFNodkVW1krNF11nbv61mENnsr7RLY z8d3RScoqBJQRzvrnS5d4aiLHt8dOi1rW7XEuU+dbGsmcZLlqehiEip3uFgHAKACUB+melmQ c3rz8fHx8X19iO+sbWzDwDgAAHT3NXmp7BLYz6sg33HhK+gcxvGgmoJoQ1HWjzMfHx/fd3x8 Cq6VHdwORQBMjHQkO14QOMwY/XfHrijEL3fwEP4bqCU6I0/w8fPxHdOLxVft0Cvhdxe/Gbj/ iAKz1G+fPcDDse601C2OA+m8Cp82zSCx7/XtiDc3E+JpLsnPzy9hhq/qgBDCdQh74jQuC+3n VWrPUf5LHlnDC6z1VjjekjrN1rKiJ4kL7q1ShzI8LvEfUcDiqyYhnJjsDlT7UuCAJO1PCCGE b9/C0ThvDaHDvFr+8kuB06ZZeV0P6ffy89NGe+CmllbcKHy7CSscUZK0fuz5UuCyadYwfWfb +vxmt7vG5SP0Ae05JnDZIyvXzuAjNPeZMVuQ46Fwiq2DZ87ddc6GkMHiV+cH0t0v8h/+hp8r jtzS9mP5Yd5REW8iwWPEAvz8kuiUWg4AOVER789W+sCxa9pevSxq7+tzbzrd1C4e5vEAD9y6 rpvQ+06tFe54uPEmw07wJG2ke45fv+rVM7ZEjjWVEOTnP3j+vmb25kxbjIfajcP8Z8/fd82m S4e3l8cai7O1e5tHu5tvYLmdqQQziwL8/FLolEC/WGNxfn6BXbulcAN1FHo33rxKY3aDNh34 +U+r+BWwShnMkN1c5Tjnzp7jgte8e9+j8fK+WB17laZ67cQ+Zl1fX/MkTaT4GIsJ8h88Lqjn 3QuXX0AIpxrw4a5yRsmvO3yVzwky8i6wa/cZc1JBD3MrNw3u+7i7YvNbfVX5+Rn18h+6IKKT A2eZm/bXZl+2uSqf+3EfP4/Yc1xQ0KdvYpl7++54fQJa5fhP/1TPGfgYtXv2WGnrSTG8yM/P cFA9d1HUPYdT/fw1LMUYip5k7d5RFX9s2Ucb+UII4dpMT6vLhbM/Mlo+dHGvbu7IHK3llZme FJcL/PSLdFPcNxCWRiIeXKel/es9Z9Dk4j562t+8XC/FXHlwgp+tk6oBH9NJGty3C/X0Du9K Rl7YSs7BkzcRfn1bW6rXpruanS+c/mE3P1ccvIdAJLGLwqxNrzc7K5z+Yetx7/qGXyYsq4nb uWKZ0pnkfIGfpeK9u/fetMincGowTecSHWTYHgz/+SsSXiSGThqEcHmoIUWF/+h3nD28bZ2V 2stWV3OK/f9l773jmjzb/v/n93uee3TQu1S9aWqr1qpVcYMDGTJkyd5777333mEpMpS9Z5wR BwjKUkSMtloRkCGikIRA2Htc3z9CJiiCA9se79fnH8iRc19n4JPrOg/LAyxRC3LzIlMIUppo IX1ssUXLsX4Th8rZC/c6KV3w5+GYT817REsBXYXMTCBNib5q/JzzsVtUzrbWUXo/3DFyz1+d a/v84PzMvVkk5PoNL4OVnLlP69ClfB9lpg4d0VJiTjIw/AJ3z5/nwK8/LuzK9hM2NnnL98MZ Sq71Yyh5p8A2yyvtBIoh3fMCl+XHwzH/Io+2SkQNgkwiSEmCyQkBDg4ODo4fNvxyyPXGrWf9 CNL8tCpEi4NjwQQyvpdC3bV4cxnWCM6ft1kmdRBZD3l7V6YRpPGij6riTuZqdYLp1VIgPiVn ax2iZ/Ll3LzdJKkjx8NIQoCDg/OYilUxQhxBOi56ebKUNc8PHByHDONv32Z5vKDpakWwNMOs SJ2wL3jK+GjCu9JxN8vDfP9iNXNwcOw1tE+k/IEyiSA34o0k+BcN++kXDrXk4nrKpxFhqDfL mXvnXtYgSb3QczWLNGAaQRoveCgpMPRe0ufquUUyIQyN9tckKO3l/YVju7S9Y2H7wgjgI7Ha 5j6xq7uj5Q2pIDtedhHfHvysuaWlk9jL8IB6Xy+pu73pedOiJTY1Nr14TeolkclkMqkH/6qj uYGeZJEpWV5Ly4suIu0RezKZROh+1drQSA9+1tjY0oHvXZDLswf/6kXb8+dNL7pJvX1kMr7r ZVtLE+1HMplMJvf2kPAdLY2L18zQI3zXyzZab5vaX73Ck8gkAulVa+N8O5gT25Lw+FdtzQ0N z2hdeHz7j4uO3Cs29/t6ycTOFy30bHmUWWnr7GI4n6IH/+pF2yKj/ayhobn9FYHqPfaRyd2d rc+b3zQpvb0s5gu+s7WNKbqp5cXrLkYbkKW/TLHtL14vYhm+GSKhu6OVWlRjy4uOLgKp51V7 Y2NjQ0Nze2dnN5HU/aKl8dmzhpb2zm4CmUwm95LJ3S9ZerRovSRCD33KKP1tf937+kXr8+aG hqbnbS+6aQcsMDWD0pbGplbGZdbXSyJ2Pm9pYu10Y0tHR9cy86bSe9/V3fGcsazWjk58z6v2 xmeNDU0tHZRhp5n7GVh854sm+oXT2Nza+orYS89eSjP3a3972caY27K5vfMV49EmJDy+s61p 0Rl8Y49ekcnZHkJCWoYRcbWLHJOybHpedzKlJqbNL2M7CT2vWhmv12eNTc0dBMIKE/lSS2XJ 3drc3k4fnR58Zzv9xfmkuCTS/KQsMuwkQterVqbdbOWNpJn7Vb8xD05TawfTNcjaBQaa2l+/ ZnmqgoTvZoluaml+0c2wcmgwd3++u8w5csmUDepl+/Mmlg2q/RXTDLJmWKUU19Tc9rqX4Wyh PjKZ+Lr9+fNG1sAF9faQel61P3vGGkjrUQelR4vNYC+xp/vFc2pi36aW9o5uasksg9PY2vpb af0KE+pSOkRaZHAWZFcmdb9tBrve47kY1pKfMy3v7kWWdw+pp7ONOrCNz1tbX/X09fWRyfjX Ha0LJnBhj3rJ5K6XLc0LPmKet7S/6mb4KF8mvaSerpfPn7HsuC0vCaxpqomvXzOts+ct7R2v ifM9et7+6hWB3EfqIb5sfr5g96b0uLG57SWhj8RyveJfdrQy9Kmp/eVKZqWPTCa+blu4vBsa GhoanjU2NL98TSSRyGQyuYdEpM8CK00tzzvwffNLloh//aJ1QS8aGto6CT2LfRT1knq6XjbT R7Kx6XlbV99i+xOJ2P3yRVPDs/lF+F7b7F+AP425PzuNjPb10DMYMqaCJPUMjC8ZTCCPjk0y 3d47OdLfT1ykvK6urq4uUv8I5X78WQSZHOkj9ixWc1cXvos4ODo1w1ju+EAPicAYQ+gdHBub RpiZmZkaHSR24XuHRsanEWR6enKor6urm0T5EUEQBJmbQ6ZGBvvo6R1Z+90/OjY5S38vJX1f T1/fyBQyN4eMD/TT20HsH6Umtp2dmZsc7CPSUgniuwgDo09Oe7yPuT89NjbYS2BuHaFnYBRB qLkqqf1dbAx7+oZG6CeWTI6PkElvmpTRCRa3Ynp8ZIgpuhtP7BucQmbmaIuBpb+MsT3EvpEp BJlD3pHZubnRASJhvqd4InFwcnpmbKSfROzq6ib09I3OTU8OD/YR8V0EQs/g2Hz3F/Ro0XpZ p4zS36Eh6ntJQ1MT04s1gzrgvUNjjCljp8cGB3sXjDeeSBycmp555x4zMjM1N8o4kPgu4uDY 9OggmUTs6sYTydRhp5j7rvlzk697CUSGcSf0j43R0yvTzP1LTyeHeqkLuIsykmPINC1wdnpu crCXsNgMvq1Hddfi7DT3KTtWj3WPzC54dbl9n5xkSk1MIJJo80tlbg4ZHyAzX/z43qGhlSfy RRAEmZ2enBwkEPD0/nb3jU3NUGqemZ4cHSRQL6v5pLhzCDI+TCbR9jZC/9g4NWns3Nzs+ACR uY1d+L4VNZJm7qfcmxxhHJxuQg95iOEanE8/u9jF391DJo8wb46z07MTA6zTTRoenWDdQxFk ZnpyZIDAuKssyJFLYXpsdICl06wzODM1McqYYZVKT//oKNN5StMTowNkAkvUwnops9Dzhk+Y 7q5eSo/mu9DNOINzc8jU8EAvcb5f3d29w9PzvZ8fnO5u6kh343vGHkfavY+5v3BwFmRXZk0g /PYZXA6sJeOJ3eSxafryXjA4lIHtow1sN3V5T01NDDJuI8yzzdijibHhhR8x+O5u8vD0zEp7 MocgU2MDvSQ8S7WDrGmqZ6ZmRxhXN767u294emSgr4fY1YUnkshjyMwsMj06MEB64yd/3/A4 6/U6NTY+yNCn7p6e/tHlfLTRmJ4Y6Se/qWZ8X/8w5Q8Ulllgoburd5j659bM7MxIPwG/oMie vsHRxRLHzCHI1OgAibH3PQNjo4ucaTY7OzsxTMITu7u6Sf39oytfhMByWW1zH/hotNRezLHe v08rtaimeaXHKwAABZq5n3VtiUiauf9wJV8pvRViZ+NvaYrishauMdf/9kcxfzRo5v7dlbjK wAehuTI3zerwDq3sK/WtsHsDwN+WP425D3w05mZncTFyhhbe7llP3uvwEgBAEKq571ZAf25j UWjmfnHTR2gE4c5JtLPhccPUxvnDgoAPDc3cT1s0RznwKZgeH74fIaplHhhQ2LDSw3EAAACW AZj7fxmant4/n+Tu7u0+j4O9vbGZVXDhg99bwB0C3oPu5o76/NN+pnK7Dx6XUNR2d/cJRKdU dDUtPPGlqab2XJCNlRQnildBx9zGPTAy8VwpU4rgldBWlZsbG+Du7u5ib2XI/z2KU0BI0SM2 s6R+5adtAIvzEnfjeoKthTofxw4ZPWNbd/fo2KxSGOePT+PjmqJEd3dP6u5tZ2dnamkfcu5x Q/uHeEIFAIA/J2Du//0YnZt7Upp8OiaAjrWlpX9S8a1nbzVjAeDtzM0iPXXlBWg7RWnhXXzK AQEeAQHJV397uPDElxHSNCUZL5+YiLCmTUBIUHBicUNv9+gipb47I52PH12aX9cOqny83Hs3 8JsFh5y7Qxx4zxTKAAuT/V2dN0+fdpHiPSZ1XN48ICAyOPR8LWkQdpCPzPDUxKNr8dGnqFu3 v5+fpblFYFppzfNlZtEAAABYEWDu/2X4rb70tIuYmJTYPLJ69naZvzMchg4AK+LV45ayKAt5 aRnq0pJR0XY71/nbwmyyj7DXTlqI0VE2cDqV/Zi83Cy/LDRcCAm2UhRjwsjKN+smQ1YM4IPQ cjsz3UuNaZz9s8tgnD86D+9go5zExCSo4y5n5Oqa++Q9j34CAODPDpj7fz8G52Zvp9gaGkhR kZY2iKkAbwh4X+ZmkJfYzAArLSk6tvFl1Ay6DAy8miwPtNRToUYpyMpbxda8Xm6WXxb6n926 Ga0vxYS6nELYuQ4i/r0KBlgZIzx/lm5qqCFHHWcNeUX0hc75DLrAR6N/YrT0jKm2HnXcZeSV jOJr69vhmSsAAD4RYO4DAAAAAAAAwOcFmPsAAAAAAAAAACwJmPsAAAAAAAAA8HkB5j4AAAAA AAAAAEsC5j4AAAAAAAAAfF6AuQ8AAAAAAAAAwJKAuQ8AAAAAAAAAnxdg7gMAAAAAAAAAsCRg 7gMAAAAAAADA5wWY+wAAAAAAAAAALAmY+wAAAAAAAADweQHmPgAAAAAAAAAASwLmPgAAAAAA AAB8XoC5DwAAAAAAAADAkoC5DwAAAAAAAACfF2DuAwAAAAAAAACwJGDuAwAAAAAAAMDnBZj7 AAAAAAAAAAAsCZj7AAAAAAAAAPB5AeY+AAAAAAAAAABLAuY+AAAAAAAAAHxegLkPAAAAAAAA AMCSgLkPAAAAAAAAAJ8XYO4DAAAAAAAAALAkYO4DAAAAAAAAwOcFmPsAAAAAAAAAACwJmPsA AAAAAAAA8HkB5j4AAAAAAAAAAEsC5j4AAAAAAAAAfF6AuQ8AAAAAAAAAwJKAuQ8AAAAAAAAA nxdg7gMAAAAAAAAAsCRg7gMAAAAAAADA5wWY+wAAAAAAAAAALAmY+wAAAAAAAADweQHmPgAA AAAAAAAASwLmPgAAAAAAAAB8XoC5DwAAAAAAAADAkoC5DwAAAAAAAACfF2DuAwAAAAAAAACw JGDuAwAAAAAAAMDnBZj7AAAAAAAAAAAsCZj7AAAAAAAAAPB5AeY+AAAAAAAAAABLAuY+AAAA AAAAAHxegLkPAAAAAAAAAMCSgLkPAAAAAAAAAJ8XYO4DAAAAAAAAALAkYO4DAAAAAAAAwOcF mPsAAAAAAAAAACwJmPsAAAAAAAAA8HkB5j4AAAAAAAAAAEsC5j4AAAAAAAAAfF6AuQ8AAAAA AAAAwJKAuQ8AAAAAAAAAnxdg7gMAAAAAAAAAsCRg7gMAAAAAAADA5wWY+wAAAAAAAAAALAmY +wAAAAAAAADweQHmPgAAAAAAAAAAS/I/pEESsZ+4KiL09uF7+kEgEAgEAoFAf0MRevtW66/Q z1+Do4Pv/Pf8BIIMg0AgEAgEAv1VNYOMrX4jPq1GkLlZZHS1WwF6H40gyOxHdPQZ+J/a2drK 2cpV0bU20uXfZkEgEAgEAoFAf0Nd7+harb9CP381zTa989/zFQgSDwKBQCAQCPRXVSdyefUb 8WmVgowPIlmr3QrQ+ygNQYY/nqHPyP9UIVVlSNmq6FJLDwaHgEAgEAgEAoH+hrr84vVq/RX6 +asBaXjnv+dLEAQNAoFAIBAI9FfVC6Rg9RvxaRWDjA0gZ1a7FaD3USyCvPuTuO8FmPsgEAgE AoFAoFUQmPtvEZj7IBAIBAKBQBSBuQ/6EwrMfRAIBAKBQCDQX1pg7r9FYO6DQCAQCAQCUQTm PuhPKDD3QX9ZzRbVT2TfIqRVjuTcm/lAZU7kVpEzysmZtUjRg1Xv4CdS4b3xnNvE5NujeXUf ahhBoJWqdijrNjmtYiQPhxStemNAINCfR2Duv0Vg7oNAK9dcGDLhP9Dn1zcYOLHqjQH9mRSG ICHjQ379ZL/+0dDVbgwIBKILzH3Qn1Bg7oP+shrILC3X599xSCvdKo34gcq842itL3jUSCYW yapd9Q5+IiVmF5vJ7vpeNse/iLDqjQH93ZUSrnrCgFslyRuHFKx6Y0Ag0J9HYO6/RWDug0Ar 12woUi7ioMit7qlWseqNAf2ZFIYgTsXB+011jljmuKx2Y0AgEF1g7oP+hAJzfxF1R56K15SR 4RKQ4RKQ4dJJt015sVjYNAb3wtfNXU5ChktAhktYg8v0Wuil3o/83+lIzm2cg67W8eMyYtYF DkWr/9/yZyxyxo2r6rvZd8jFGSd2vz049Xytm4kMjxB10gVkjkgYqsQOxt1iibxtbSB7cKeC cBSS+YHN/cd+AcHSAqpHpb3MCoaT7nzCgbr1KDwiVERA+aBAgFVe25kFAWfSz+kLrv2XYJJX 3hLDCFq+pjC4dm9HRxkJGUHtcONMJLdu1Zv06ZRfRYgPdZCSU+YSkOES0D+mdNb7zkTG2991 xkuGV36beLQrDsn/sO3JzzE3M+UStRIyuXyydip3tQfnQ+reAAabr6thyCtgLeeADcUhhave JNDbhE8tPq8lrMAnYKjkdzvo5qq35y8iMPffor+4ud9sUBKvErSuAAAgAElEQVTLKyOzgy4j IYd0m9VvGOgTyb+n3TjLfIeO4g77eKMbzz90+bOhyDVeg2OcolaKJavf2c9GA46tZdLmMjsU ZXbIyOww8VXMfLTaTXqHNrfclDaT2akoI3zmln3LR68xFEEcMK7bVaT2aiQ5rbQQP2KLUYbZ Di3FHQ5nTW+2rPYYgpYt944naoEyO1VkDoacs8aRVr09IDQC5j7oT6m/jbmfUlTp5ROgakaX pmumZRphsQNb+uIysfZ2Pkr6zkrH934v6KcS+mSxfxRnMDh8xMlUM2sfJQ0jKUHufwkmuWW/ fs9/PvPK2xOSMp3zR5OqFg0Yz6t+HuAdpiyyn08zQj1p9f9b/ow1llvV7O8Vah5VF4odeltk 6ZOQgFCegyLC+u5yxj5Kxj5Kxj6q1lHW2SMLZqE9IiHP1iPf5RySd//DtrYtIiFRTVJh98/C Monk04vP/sdRVUtsaqK6msLGf8mrxf8WvSAg8+rT4OAwteAHsSVvGMZ7I5hzF11TG9DFw5+m zVmXa4PCTqqaBauaxTlldyZUM7x661FwdJquWYCqVZRqyMO4jGKf0Dj6he94wTO3I+lmS8zp WE3LQOovUw1imnKpW0Hm1achgQEaFtSNwi3VNK7e2z3RN59S0UD27XvONqE6Zkz7CU0a9nG2 uePJ1e/Yl2kMDo+OSNSROy4gbSh6Esm+9wmnfrVVcIecnHTWxD5QydjkmJD8tg0WFpWjKW9/ 1+Vyz8B8M/TdmA/uUF8u93SzOnpMYeOR6KCaiazVHpxlKa+KHB2eGHC+60zNYgF1I5iS247u HkIHNYSUTrqtykMPd/Dpl6tMwh8nlY2s+nC9v5Jyq8OSykLKkMKPcj5bX8bN2/Zm5oc3Hzxm nO1YvLJCWsNTav3OPEv99AdY3Xh4KrvCLqunsH5u1WeKUWDuv0V/GnN/KgDpNsEkSIUHiAaw KFwhociqG0FPsb7L5UGioI/mHgkLYR8fqqKVz5Y4r+7/YK8f6GET5xsfg7V/+joQQdBjfZ5P CkVPh4sGBIiGJ2li6n2QuTCkxag4S4aps9HqmAonEkNpo68dHmPnY6LzTSqa/BEEPTcX1lKq mBVDf2MM1r6hK5Dylrm5MFK9ZmGiJL3YLLOH1Ya4KqOUsuXdRDw3F9ZSqsBYEVWSJ89o3e5G D02taJRGfWefaBZWOdPavFIFDuBtb54SdpFeq+6tllj/oWdzLgxpNriUpp551frj28F/Ho24 dz/SjvER9vcRNhBHyescdSv9AMV21hnfrzH7WAboiHvXQ9WTHpxH1nK6Zpk8+OijFIYg3k9L 1YpytM498HljGMmp+6FBYqVX30jIYgGB/V02JdGCTifWqPlppuI+yeSClqPhl7aN1ToXGtBD E4sGeBPajbPcBXW411vF619/tfoNBiHM5r73szvG6QwfbGkFKleqTZJSTFoGvMcQNDLs2/nA MC5AMpjy6mXdR71hU+PetdlqCWGiAQGikWclLzb4DU/SCgydGHO6Gqt0klpmCFr2WpMLceyt r3a7PbyhfYreDNmCctMn+CBcvkxUKMtHr1JJgx2euT89z1zK0xd+SIsGBEgX3bVoHUR/Nub+ 9ERQU7HqnScurUOrvwz+bPrbmPvxyXnmWlIHeMUP7N++9pv1a9dw/MglvkmzLLZy4o02x50+ TIT+AeXIN5j7DLp+P9FH/T9iae9v7mecu+VnIsDn34O+8bawWH8TXad4MPc/iHKz0u2MdL4/ nhFWOZazmi15HR1/VmGvsELSpzX3cQgG9zLlSjL/Nyq6i5n7S6uGiAnXFrLCmCbjP02D03Iv Wmsf/4n9H198sYXT5IrLOfq3DtmZkcoSXN98/T3bBpG9xtcjouIszdW2bd/O/u8NG49I7JaO MIn9I/bKg1B3oyOCMls3rOX4aft6fkdh17rsu9MYHJJ57VlAcKS8hAA3/4kDfFIH+KQOiGpw yVkcQXGe8L3rX4pgcB3JV+L41u3i3CO0m0/qwMGjnFvW/+/avVv3Hz/AJ7V3/6GdnLu5ffoj SpbXo8TYCGsbu7+buc+ghwEhYfwbLCyXNPc/qq5dc3Px3PknNPczr7fZi+5Vj6wPfNtd3s3u 1mFaOqtk7t/6LTYuYKNIDvrchzokbTUV5h1kZOyqj0EK6j9SFWMY3CMTMWkFyxWb+6VmFlHK eudOfnpzPzvJ2c2Xy6Uh//7sqs8Uo8Dcf4v+NOb+hC/Sohpivl9VaruU6MZjXGu++mrNAYEt olLbpVSPmgXrtSDocZa3DGufNOU20j1R0Lnq/3QxqemqbITODwe2fPXVlk0q4cbVzf4Igh7q dr4dtF16179+3vb9YV3xkKvuyFwYglOK8+CWktoqIoDa8tX//LBjHceWHWoOqjXD9NIGms1u R++V4lvz/Vf/u477kE2yNRFBz82F4VJ4PQx+4d2/bss6ti382zWjTWue+yNI8Nigx7Pbeuk+ XKbq26Wk5nVMQyDEcrelycGDzobL6svcXNiDlKMeChy7tn33n80/0QqUktquqHnQNsa0pj2g f3J544MgaKTXeTp3l1ygPuYtvue7N3Im9FnsTr94rQ9v7oOWUu1pLn/nD2Pu18Yciw0RS2z6 eK31nhxXtd5xIORTmPvvpkY9XPLRvX62LcSgN8XMTgY1nPrVO0EXzP3PUIRqpQvB+zWK0F2D b4yZGg24YrENnQ3m/ucimrnv24rTP+vFpy5I/2DT0t2pprdnG7fAtU57MoJGyJ7PsAr6PD9y fLdm16Et1qekb3aFToy4XfAS1j36/dYtbJwyv0bd8SRTvPuJwL4Xdjcwx3WF98oIb5eS2i4l /quM8GbdEKnMStvWnkAECRkbsow34pPevm7rL19uPbJDQeXgmTqbjhb7G4mSese3ie399sv1 6w4c3ROYoV7RFnDD76CW0nYpnvXbt367dut6KaltUlJ8SXdM2pj78/KuTYbNNrG9337xw7oD Rzcxfk4beggn3bBsJn0m5v74oN9lk1/Cco1KX6/+Mviz6W9j7lP+tSuqHcjN8BHhNhCT1FCw 0GPf7e9WMpj+pn/OP625X3B3IPMWISblnJP2kcPOT73y8ckl+OQSfHIpIblsMOfeNONtqhRz XzVhPOc2PqUUn1yCT77Zm145VsDyb/yDWUzdcOatnpQSamkl+ORbQ9l3p97nP+TCe+M5t/HJ pfMFppSTMmpGM0r7s2unChheTakYyakZyavqpVdd1p9RPclSWlH9TG4lMfUmQwtLejJqJvMW mxfW4FJiatVEdkV/ds1oLv1W+oncanIatbSUisUT6hbVz+RWEFJv4iPCArXUlbYZV5zCvqL2 iDllbv10Ye1g2k384q8yqn4ir4acyjjaN3tTK8cXu4FxIreK3sjkkt6M6rbw9zD3C+sm8ip7 UkoZq+5JvzO7iPfE0sibfelVzYms5v4cBjeVU9k73+vSNyTUrRvLrepNvvxHsrcSr0GyduTj ZMYe1YyzHpxSP1VYO5hGa2RpT0r5YE4VKb16bLlJjxNSi4z4/rl5596vDvqoh/yWex/B4GYx uPFIN13BY5xs+1R3K17OqqEstt8Cw9B8680sK0aSmQvxMRGRMw7TTqVPSqiPi/wJKS73xqy7 8+05m3XJRGTdN//ayu9BNfevZfDt8HZMb0nGIZjiO7GeWl8ez/DOx2NwSHrhdR9T0aMBgys0 96Nns2uGM8qpF+ziwz6dV9OfwXS9kN4rwez9yYKavmSmlUNMrZqkG3MPZjB3+9PLick3+9Kr hvPuj2SU4qlbCjGlbDCnfq6Qpaiy/qw7I7l3B9PftZFLmPuFdeO5lT3URr6tqMLa4ezbRIbB wafc6l/8gq0dyrrdw7QxXsK+l7lfP1Vwd4C+vEsIKWV9WffmCpirzqvuTS+jDt2DucL7o9kV vSnU6c5fZtrq/DuDmeX403l1JgI75XxvuBYyb/W10wzBFHM/0uX+SBptBsvJ6TXTRQ8WbFAs g1OCT7k9mHV3elltoy6w0eyK3pRzZcEhzj/yx3ul/MG01d+ZymfaoyZyqvoYNkbKBjXO8tFW VD9dUE1KK8MnlxBTbw/l1M0WPRjLutWTWoJPLiWl3h7JfzBHiy+6P51bgad+ahBTygdyH0xm V5DSbrJ0fyrvzkA6Y9WLFDVFKcrL3k1Ty0otGX/2Bu3TrTe1amKRkXwnTRfWDTNdVuWE3AeP jFjN/em86v50lmu/kuVaoBVVqKPnJ62aElCCT6JfCwPM1wJLvfjkUmJy2VBO3cwij8XUTxXc HUil796klPLB3Kqe9Oqx3HuzGByCqZ/B3CWnlRGS4yItrB33Wladvd6dTO/RYO6DOdZia4cy mZZZb2bNBPOnxkz+3aHMMsoID2TdnSy8P0Hbr1JuD9E2agwOwdwfz61m/vwt62OcFDD336I/ jbnPKJLV0/NCv/4qdO4PD9LCV6eDp4Z98XgvfLW4g95RPQflarwXniKS/8DoojfALqXpwCGy D5FWzvsUhaARBN37SAcbtPuAq+H9Nv+JaTSCoOdmQiYHvc87bnILV2E9w2Ta8yVOyXb7P/Xi pDQk9xkqC538nbnqEY/ZB4IKO9m///d6UTMZzGAw9SW3ugJJT4ldXg/RXaNoBEHPTnq03Vdw 2PvlDlXp3Co3StjcXNjzdG59/m++2bFtueb+vOrkzgbyM7/XpQ0no/8th22OfR0hDEHQCBI2 Nxc0SPLuYRzGHv+h8ZAZxqImA0cHfPANFq/jf5VwUUsucaAH430HRoMXPJ8ROj0ZQMZ7EeZj vIkk36GpoP6+gFFqyTRzP74mcLiXWhrRr384eHqlMzg7GTQ24E1tmM/bE+pOTzDUi/fq6fMl DweS8X6jU6Era8DcXNj0iB+ZxDCSfYHDg36jIwHMNwizDI4XoceXPIaemZ3vwmi/N+W9A2Tf AZIXnuCDJwdNzQSNDPiS8LQfwxAkZGLEvxfvhcf7DIyHjg75DzBUTRoIGn3z8xlLmPszQWND vkxXVo9v71AwY8zsdMgY2YtI8CoO5An2OBZ+523ByGzI3JgficgQg/fqGQganwpbUHXI1Kgf fTUSfEj9biPjqlbLNvdDxkf8eqnLjzwcPD5D+f18ytw+amP6RkImplknhdC7WELduTBk3L+/ 1xtfo1oaxb3Tyaj2Dzdqd7zxBL+RafrKoZn7iXcDhz7Q8mYdHLwXnuBD6A+anmEcxjAECR7p n18qlFenxwMG+7yp/Q2dnJ5fh3OzQYM93kTqlM3NhU2P+FIWMKHHt5+6JqkbRfBInzeJ8NYZ nAwc6fehVzQTOjnq3z8/1L6DYywbBeMceeHxPn19fkMj/gt69MFE6WAfyevJZek0990KSV6/ PaeNpDeBFDA+HTZLDaaa+7qXn9O64IXv9R8cW/ARMxMyO+rXs2B5Tyxc3ssQ49B54fHevWS/ geEAEilgYobeyLm5sPEBn16mqr3Jw8ETM8ylTQdNDPlSAnoHg8amQqcnAwd7KKvdhzwUNIGE zc0Gj/R59xDoA9I3Ejo5GTQ6yLgVUIKZlxlNRL/+EdblPTMVPEr2IhKo750NnZ307yN6E/Be +B6/PpaN4q16gRSgkTk0Mm4SosZjYnokv432mtPVGFHx77/4lpvnCsXcR9DIYFB/1QkRfqGE 64avGUppy1f089yln2aLIMHzq7Ddviya58CGNRqJevUU93ooaPCOvMq+n/YpcqEv247OXzDo 6nAJH7ctvuXMLesO6Ms4/LOW5Lm7tky/r9YO8zks6qeFIAFv7FV3QF/GoY2aLO+1jDc6qK64 3ecKenysf3Z55v7ksF8/yQuP9yYQ/EZmQmemGWawL3B8krqtzYUhU4GDfcx/QfX6DzEv76nx gKFer47nThnam7wSNAp/WyyYXpQPqS9gHEHPImgECR4fpl7dPf4jE9S/KBjqJfT49g6HzMyG UdvshSf4Dk6ETs+ikZngyRHKXuc7OB40Msp0DQ4tvAbfUdMs69kL3+PXN7yMRbh8/c3M/dzb 3R5qW7mVInRPXvQP9+Jac1wpkfRGI/XTmvsJ4a4ygpzfsq/5+st//pONg+07FPtaFPtaFDvH VvbdPuYZrYyeF8Xcl3AqtRBH/fADin0tin2zwmGD86dYbsmsG8Sci5U9xvPjWmppa1Hs/EG6 JxtX3E4MDknKvWEhjkKh5gvcxCMh6JsnuMHc5OzjUwyv/qyUauWd6GkqRa/6gKmgyz2W0nJu vXbX2L17C62FG9jX8oj61i160DBL8NqNe7eZVOuqmpp6ZznRHZA7TjYG+6mVblZePKFuzq3X 7uqcu7eg/vOfb7784ov/+2rdt2uoPWJJmVvZlHzG88CmzRyLvsqo0kp/d+Ota1FraF3+VXKL Tkl69cSC4DuO1vr76fMie9w5yfw9zP3M8xXeBkd+WP8jbbQ5fjnEH9gXvXAYSyv93Iy2rkV9 R4n8RYnH6HTAlWReJnN/EoNrsNOS5voZxb4Wxb5+F/uJxRLqFp1zMz7BvoaDne2Lf37J/uV/ ONgZeiTqei2EJb6yMTHeff/Gnykjyf4T/4YjPjbmwnzWGJuM5d3Pm5BaZCq+9pBL9L6tsmLa Gc5XEQxuBIMr1uQ/ISIqy2MauCJzv8bWwE1SNMi2eiqP6gcV3MOfLcyV3bpP1u/jm/vh5Oy8 k5JHD81fsD/uYT+RG3iOJWVIm6+7rdA2hit6rSCX0lmvFZ9Bf60u3lMNtf4nWoFrf+b61ayO fshSNQFz0vII1y72X1R4TeIDriSJbtj803zwgY17PWyrxlKpRcV5qKHW/8S+w0o5JNUxyouH fi0IcSmdfXMW3CXM/QzMTU+9wxyo9ZSi3pJQN+lsvIHMPobBQW0WsJSPR/IWJjNICVeR5KFH Hgs38Tn9XuZ+xdOE06571m+cX95rt/3IqaWaNcpyVE6AtQL/HhT7Wq5N+z3tasZTL+caqp7Y tBbF/tN+dqmCkAukZVUaFeonz4P69rv/fvWv//v3N2vpHxxrUeyCESZxzxmCKea+g+mlM8Lr N1LWGIpbm8+rObduwR3WyWHKEjyMw7hBLEDtZOdKFtjlHAMVyU1r1n3zDdv//vNbNnbaLrGR fS2vRMjjsHLG+CpbY829jB9YW9QELIpPM5/ClFf+ItpOZM+Ozexrd3OeCDa7MFhQf1njGN+2 tSj2DcJbT6Sg703THsPKutHsovjz9s2UArl/PuDsUPtIX1l03yYU6qAOv3dz3vz3WL8Hod14 aBvjWhT7BuFtUqmMRWVeb6QUxfY125dffv0FO+pbWvAOeU6j8kW+AX0ndZw9H3/8hw3UT2ru zdzODrX31VnN/VZvJwsBpmtf+JBGqg/T4HScPR8vgvrpx7XfffnlN//+gv0bhsH8RchO8Qzj 0wa0YGoMahf73mD7wldpCxt5+0lstBPn9z/+lxK5UeQXXk8HKwEe68tOOb0YHIKp7MREmRzY s4P92/989fXX//hqHX1w1nL/ctDX4d50OkuZScEKYkcYuqN4wrcczRTTFRkTKc2J+m4din2n nXoE7mxx9UlX5TX/Xc++FrVBPFjz9Ct68I1SdzudLYyLZ6fiLuPygvr55Q3m/lv0FzT3202f nN6FQrGh1v376y//+eXXX6xDsaEoEuV3ybRdSY3PlSOMtu6hlfM+RSFoBEHPTAZ1PzZJVP7K OtWush2NIOjRbqffw35W9FDJqXYfYbnVvd34YSwX2/ajaQ+dMdEH7fX2aKQwnyxEMfeP81rI b9E15xIKMKG+xGru9z7SvhS4a5+jYVWD98jE/P/ec3NhUyO+fSUSaPejH87cD5km2JPidyiF GF545IsgaATxnZ3V9jv+40HaGP7wDeoQf0SxHaMfgjxUybTfguL4CvXt//2b7Qv2tV9Tx/wb FGq3S4H5b6y1u7Y9ktZHsf06H7Zuv+Du0N+0zdWlC67Ol0wz913DVaIVqbXv3W8abbjis3R6 H+oU2f1IbdvWtyfUbS1XpteLYjuivtcgWtlo46HMBveOFdU+OxPyPJVLV2TtfJnr/4NSlo32 OJx9Vjq4gjHSpeXBCX0U2zZq1Tt5d5hcRncOoBEE3YvTLrT9kfJeVwNOOxE21M6NG020G19p p9pxiqAoP+o0vvJHEJvydF4F1Hc/bvjF+YprRiSvnQi9O2Kumnm/v7GpS5j7nfrnAvdyM15Z R/bKhJgyDXWLdZEeG9c2trXf/PMbtn/9Z93bgpFe5/EiLiGutbSYH3769pCz7o0//FirJlk/ zj/Ki2LbSIncvk3UUurRuKrJss1965vJR+Xnl+hPeicNy7oov59Pmau2mw2FYvtx43cqCU53 X6IRxOX5/RO6KLatKDYUim2H5GIJdaeDkTJha7n1qHVfrP3PP/7v66/+y0Hr9X83bj6c0Oz5 krYYqOa+R5hihDw1bB+X5Wnj1pUub4Rk/Xsew+Cg2FCcmzab6bZ0M5qHoQhilGy9U4jh1c4r ov6q36NQbD9tWqN6xrn2JSXSZ3xEw5P/By4UG4pnv0KY2cxkUHPyPm2htSgUGyc/pwUW3U0/ hSNwctQqWesnwW3zVa/f+N1hV/2bT5lnsF4h0foXWkX3Ot3vFx635mZDof6DQu3xvGj5hHmO ShJ55OjLbJuWFnd4isAWC91W/Jvt0PfQzERgU9I+TcG1HGv+zc72jy/Y2Ti+p9a++cdfxKWu d/r2U4Op5r68f6SINTc1TFIooMieteQep6H8A7x719CW9/qNaw67GZQ3LFjey5B7XYGIFRdt cH6Q0jngHCMhKi5165UfvZFjAaVuG6QP0MK+QaE2GMQa3+5mLq3ZoCZsJyVG0ksH84d3B07V /yjbjg1sKNSvukGa1UjA+JBFovp6ga3zRW34ZZ1akmt9rU6ez24u+hxRgtEIEoIghmdMtwsy 7hL7uW3PmLQzd4TYYJarw7Zny/x7a4bdhmqPqx5YtxXFhuI9oBpp/u5j8gIpQCOTaKRERsvy mEuKHs1zR5CQsTa7G6eP7uYWvL5sc9/p2ukTJoKbPMttWvuCJinfisyGzU4EkPB6fkpHzCyO FrTPv/dTmfvBw32WOQHiFgrCxWNdI8sz9+sSDpodY0Ohvt/KeTSl0+d1h0625y4uFBtq4xqU umLxA4/5yOkgpFHeS3nTLsYZPCESdt6BsbSmqzIhsmyo779m//J/2b798juOxYLpRW0S0ZS6 iqBHEDSCWF49fVgGxYb68TvUEaGzlU54er1ylHp/ObJDOsaBMBBSF89tdowNhVqzeft2z3Kv pgE0QrSoSz98FPXtBtRe32vaKVmC5lz0etEXHJY1JnR1aGe5c3IxdpmPWzPa4j2u0yX19zL3 SRmll+S3cQpbXna5QEzMxpiKHdqkfcX33Buy4H5acz/72u8RqTfs3ILUxTh3auTo+mFdo7Gu 0VjXk9dczzyJKx/OYwiO9TeROn70h0MGR3Vi7dAXXaOxrh6hunqOB/XPh9PPliFllV3TFzRV cUo0iaaWFo01MbOUVHFX8KhIWNGh1fFJOebGBkd1Yu3DL7pGY12jM8ycHYQPH1z7DxnF07go HJJ7uzs+KcfDQJhbznifiIOMaqBBNNY5GusajbV08FGQ0+WTjfOoGKF4B9lXfw/zseHVijTy LaC28JxrdKCMlJaUWZEjU8bg9piMVGUhlUMqaFqwY0iOmrzE3s27eXTP2FymRZLOnrsfEI11 CskwOLF9t0byogl1C+6NJuXe8IvDWpoZiR0X/Ek61pYyktFYr+T6iBIGB6RuKLf0ScDpq+7R WH1N5eMSb0qo+8TPK0pNzk09GutEHW1b79MaauqHlVPcMa/nM4XWDWOuFBnqmohrBKh5UufF w09JVXnn7kMbfxSWPrt8cx9b4ecXxKUYbI++QB3GPPugUOnjimJ21zwLyfTIgnxrI3sBeXd6 I91DdNRltx06yP5/Msp0c38Wgxs4k1cdEIt19Qk3Uxf9t1DaIgl1KzuTCqtcw7Jd9QR3n3AV t8pypa+0GvTFbiaH6NbD8NBIcQFzpbBzNpQY/wRLLcVfN7Ovl0ta7pE+CalFppIbePz+0FPR EFJ0lwxqwNwlYdKceY4YiWvbqnuhV2TuP3axMOU9IM/lVsdwk/Jk/h1iTHLlyWt9abXIRzT3 dcS45fy4uPWkXFNMo7Gu0Vj7wAy540eP6qU4ZdBN1cgge20zbwUn+hXt6hulp2/FK+tjXjSa vIJUzHd6sy/XesRcoRXoEJylKnuczzDdmVJv3TjmBi4oMVxSwZRrv5qMmpaE/TnLUKxrNNY1 OMna0vywoJxc4OOQa5Siyj1i3Hh4DXl5laV17eRcsU5RtEYa8kiZq8aPJlQsbMYS5n5+JT6p oMz9FNY1OlBSUE/gTQl183OMbAOOG8YwrMN0Uwc3CXFDUb+GmNKx+dKqCPEhdlKy1lKWsWbU SGMTU3Hhw1s4hdcfiQ5cgbl/uczfxe2IoKVi+IX55R2dYePnKnhITtH/acg1emTquTshZ9L1 jdz5tymp+5jxi+qJGkfqR2PtArJkRRSNE/44ucj4vFEZV/+ITMba+SbJ7tvEbxClGcCwMFIb Y0sZ82Q0u1ubH9vJ+auYjpj9BaswrGs01tIFraikJub/7PTN+cGhZt/1VLaMM6MPI9bIzF5C xUbcs37Z/nX1i9M5VV5BMSamGuv2Oui6ZVPLLHaNLg+/2p/OtJf2JBTd82eo19U1QFPV6rBK knftVCY1rLB2JPN8hV/8VV01I1lxSWlrb+5jciImSYYBWBvXMG1NPbmzk/GVCAZHissoMFRW P6gWZRpQ5BqNdQ1KtLKwOHhMc9e2HQdk7RXC6kKwQ4X1cxjc69CwCD1dRzlXrHMU7cqKtdA1 2nUs2ArTmUhZOXcGE7OLfWOxuqpaomKKwozBCTV+hYSVnDJfXh8cEigmrithf5EyKa5BZy0t TA4eO7Zh3a4jBozm/nDyBVxIHMPg+ETo6FrxKwRaXh3/aQEAACAASURBVJhOuUuJGcmpeh52 6opHtL+4pMFRYTejaKwLNd479VFUKeOd+7RgaoGh2a6murzi3loxD04xNrLsfrA/WkLYSjny ku384Jw2VZf9ZSPbesWs+a9m60Yx1+sDzlx3tbeUV1TfohDvFHWZ2tSb3kl/nKmfpV2zebdf xwVbS0hbS1vHm9Nqd/eWU7aUtMh2u0ZLZjCWcaMxIiHfNdrp0GF3iRP68hoavNIeulGXHaLP qGn4q9tgwuYfXHjk6RiqpuKjydBfG49INVVtbqUsX2xPJpj7b9Vf0Nwf8e5vtsBidbEJh1Ul d0uqCiZgdbEUVdj+3u63khqHXBvrTUto5WB1U9ECzla8lmH6rQj6Lbdsv0WTI+6v7vNby4nG XbBtHnBqK5fTFOKOLrV/Rma9t6urWjXd/KcfDfRqO/wJ9QpnHLnFFGQqEfQQvcsesw+EFMSF gk8Lh4cfkRHky2lF906gF5j73n9gZdHqnAZX/ToGFtwsTHZ90exQ9dR7JeOziLmPRnqdZ3M5 GY7WCZ6b8/ijwugmbRgv62DRR630BZzPGj5kaEb7I1NsrvxFxw2HNUVco9Ww9GG3+P2lD5mx iib9azFHlbW4bU/p5mIoMUoZSUe1BNZv5eQJO29NMUAp5r6OzM97Thw28pabLy1WOMBFUD/c YGUzOEH26HxkhMXqYrEipiL7Td6cULepWOaUF0O9WMX4sMOafBvW/2N35GO35duv/j3txpnm O+V1BUJPK1PKvHxJJ97jgLbgGlEtftcSaiTRoiJTxEL7oO0p3bxzlKpVs5KP28hxWsSZ1bb6 T/R5vKxVvxC569DuDUdleNzClXJS5Bzk1ivLbjNwPRGeppoaf1z1MGdChVvroC+h3fZagowj zzp9qwNK9sfdwpWo3ZELdTykZyLypu+63mzuhyKI9ZVQ0UC74xEMV1Z2vLifNZeijXpNlx9l hU8M+XbW6ZZe0w035jTR3mdxhh6MLbOsbmBYsQOOLTflLOR50ZnqudSYSxe1w6w49VxlkkoZ vhJr1LuCFtDQ4PPH6hZSIlOkzjjt4pdav+Hr7Q7LM/d98W16BSd5jm7c45+oVd7kRZg/PTsM QQK6GixvnOL11PqZ300f+ziANIJGkIChXqc6rO41rG6KK6eByeFFEurOhiIE+4c1RtgE4ZNW 2zepSydma1F7bVB81bplKGiUGkwx9zWkN++VPmLiIz8fFiPk5yJkHG3YhqAnl73GHO9j5II0 +fyxukXUYSzMVIiy4VSzkCu670rddcMQxKv1ofntLIkoP65N8mLRxnsMDY46BMphsarnzwvo 6SgWVVCCg2em3Z/cMryZImDryMOrKphmvlNW9xg6VhmLlUtKElFVUa995T+EoBHE4+VTlSC5 LUauynEZ81VfvKAVarlT1002lTEjSJ9L60OTwuQTkWrsGn5S+gZcRkZ8DpG62IvaWG8u+9Na qfPbTiiCWF2OEvC0FPI9S102yeLBJtuO8mz8Sl2zuct/JTveUpqbCR1qtbx3Wz8r7Ki79mYB V92MQmrtV42uVjp1jwbT5mVq1P+KBUrhOIeAFr9D5HxYcjCvg7uoZw7DZdXv0FwiZ6nIh87W yKPOy8XzWqEWO3XdZNPLl5cuhTo4btWpAoGO/I6RtMtKOtJtt/jejf89cBzb4duHoBEEPYZ3 eprBY+AseTJJnRqmg8WKe5gcsPNUyWX8bm/Is+eZ+aVzGnEGKBMXfi1rARPN/YYBunkYXSya Lwgt43XTbWbKp7XW6FYkl96JLVuEeGKvGlS1BvaRPDqeWBSdFrPh+b9f5YV8Y/XrGtx7kKDJ UftLPtx+AdJR6QwX/ilBb3NefW/1Owh6jFr1+IB3R51OyVVZJ5lD1hr73cIOyYtyu2erZ2J1 44PF/FyEC9vfNQfMC6QAjUyjkfvKZvKc0maH8x4zvDwe2NfpWFnlSBzzn5/CdzT3Gwxj/XlP mEs0D/hOsjzvgPjWRJ1wddzjeMkVQUKQT2fuoxEkoC5LK1Bng3N5R++pZa2f3hbrB7dVEtHC 6lt3+Z8+pK/HZeIiHoXVPV+k6am9L/ai+aNeNIL4jvYbxqse8Y+SP8OwzycFHbWzEnA+bdxO zZY02OXcUKN7vkDdU+x7Xcfj/hkM011l/+yVP4KgkdlQZNDlyV31SAs+Ky3R8wh6GEEjiG9X s3U1VqUgn1/0sGBaqcP8JMyGIoPOT+4a34g7FuHMucdVylNxt56RoE+0MrZAsTDqsIy7ftUf Psi4T2+72bU8CYNdP8vJbVR2EnCOoixvGUetnboWYnHlnivZBEY8Xjw2L2XocmbMcW+rQxou mg/6Akfee4dZTH8ncz+v/PeoSNNfOU30Ih7HVSG51+5HuCujdriZJjUufsrz533mvqSE2Da5 KPNUQk7tDAaHYEofhwRE8gkYm58jJ9YiGBySef234AAbSZVM18Iuxg6m52FdHD3VrBPMziM5 C+9mXUqRQV5qcuIHvQnpdygWz2DK5bvujgFqJtleF6kV3SFhIvSO8svvkArTPfV7CvVbhKzL tUFe3gpSBqIxzVHl45iqtpOJWcoaznoxzxPKx6lVTGJwDX4BQWpGsTpBj+nvxV729LY9eiJc 52QrLTi/pv9kJFqW75iIEaO5P6/8iq5IKx4ew/RFzX2aEhNOmRhq77R9kl6z9KETEYEeWiqL m/vxyadNLNGa7tWMz0/k3myJiY7UUDXXPvVHaBmCwSH5lcSTHroymn6aofWRt6lvv/UwKCro xHGRTWtXYO63R0YlGRii5aMbs+incIzlVjX5e4UoaUZYnL5/BodgcNMYHCHCyUNdy0cxtIbe yJLfoyOCTogJsP9DVmnRM/ev3o330vzqeMYi5j5F73jm/vUSTyenbds9nG/Pf7WDqXyZnp6p YeGvg74fdmV5yXgTUotMJX/m8evzPR2tombKq3TaF/PQV+Mgt0K8jneibeDKzP3e06kXLMxd RJUsVUz9Fk23i8H1Z1c+cvQoj77al41jNfdzS5/HJWY65E+8c0Jd6iKMjTBW4N102EbQINsd S6BcR3nVvdHhIdIKuirul4OvIph7QxjMRV0zVy2/G0FXGd5e9TwmJU3b1FnU4cGpqx8gp3Fe xatoV7Hdgp4aIbgM+u/LLU30D26TPqaX6X5lct6QvYvPOHfO2FxNUDXLOv5lBg7B4AYxuCIl QYmDXAYyzjeCblK/JKt8HpNyRtPA4LDSDf8L5GzWSt/9zP0yS21XyUXM/QkM7qmvvb+aTaZZ 2kuG3w8mX6hytvUXUzzpeeFVKg7B4PrTb1QYiaucMMt0yu2gdTAt57yjqeqhg8fXrsTcb4vw j9CStRVxvhp2b4raO3Jm2S0HCzVhqTiTU01nmOJfRZyKO7HtAKesoaTeGce0xjM4JK+yLwp9 xv/c64RlLh7MMs7cNxHeJ3hQP9ujeCrjHoLBIRlXKr08dTlFMn0xhGwcgsGN5ZQ98TO1VLDL d8p7yTD7SGLudQdHbxmDGK+rkxkryAyx4jP3b1R42tnt36mlgx1PXFAv2sdTWXD/bjErYaNT drldZ2qQnJJnsUk5dvnTqTUIpqTSL9CPT9ZTL+5lYsUkBodg7nSn5xcZKSnt3LCPxzjb4Qp1 9nOTze3C1F1Lgxlz5N5uT0lMVlUyVQy7F3yNKQ/wBzxzPykpxcrUQsgw1/Pq9PzA3ulKKyoy MlPe+d99PDpvPXO/sinI11uEi0/k9GQs63dCKzpz/y4JUxgjul9Wwv68F2OBV684Wzty7vf3 uDc9vyputyWnpKuY+OpEPIpkHpylz9y/05WcXaQsoihmnuOS30lfZuX1ft4+8moe4i73z96f ZbjAyRhcvuwR5YMHlYV0Q/WD7iXWz+bjSKeSKgMT6k7jkCIcEnsGbWAWqes3/yPljTk3GqLC w5UVTHUS2iJvgbn/Nv0FzX2aGuV8LIQsfHSefYQ29D9TTXI/JCoiVoqgB1dYSBCC2N1wOuLs IWgbKBhqdUjBw7jutT/rf30DjlVJx03FdpiWeXYMhiD9ljdi+NSP7vb+A901Ro2hmvtRGJ1b JXIxGruPeZvc7QoYZTX33eoKZHzlDsZ0oYkry3P7Ji1i7vv2PtcrVN6kH29xs+UNSXHnwpBm VbTOfl1LqQKWLKlLn7kfhiA+z7IkY+x5zOI0yumZe316XxnkenMeO8wXzWzuayrtELdXLKqn FthpeSNO1Ej/WF43um/loxGGIPqxBnxObzb378Vyu1tymRbQOuLX+bvhhShxP3+Narxf33Jr 7LVtui6uqHDY5YzJozbKIxHoudnQnnvqCVa/aJsfcy2hDs55yVMOPOaBmrfogxPY321Zcuqg kfax+Is2zQNoZNht8r6gjOheiyDtikb//larq0Zf7RU57J1v0zgQ2PXE6KQAh0+x88NeNIKg exqtsuW/EpDfYxmnX9HoT+2+99ObatEu/BaOkhXd6OEFI/kmc392JuT5jePRvtJxBTaMz0+M vLR9VCDha34kqsLjGZm5qCXO3PfrrNUp9Be0iDf5rTdglKGi5muyUd7CEal6uN75NjekS5y0 F7BLMXpCy9VBcuq4IeVpsGnLtzvsln3mvs+Lx3pegnvS6t3bRtGkZsuKXOngRNOGvsBRBN1R ppLnvteyDN01zPrGF5hjwZ68i5j7NL3zmfsqijtOOCnRc/O+tLhy6riJsVABHj2wzOXdeU85 O1LUN8L4D4ZEJhNkj5cl0tGOPOHnLKtYbtYmmNfn8ezYuVlLi9/5pN6Nh54IEjg1aXc12+RR o9cAY2S7ZnrQgUOHd5iai3qkmP/+wg9BfIivrYvOmLT0BY4haFKTXnHcAWU1scRbPi+osz8z Fdx0VcbXlts9QuVWG1PVQ21Wd93+Kyy+T85MIDDboLwVjcyEIE36N2psKblMECQEQfSiNbis TWXP0TYZsv2jGypRYbJBGHvS4Ec9KOMdz9z3v2KxVlGeUz/SsLx1/pfkJ+qJAUIG1koN898+ +r2s0SrwF7I+a/KEHEhztGemgpuKZSK8hKMzDB71Lrd5oQhiX+Cwy95CJIqej8T92R2tlECp oLMmz/oDxxA0MuzWdlfd25Ln5CX7ZnwQw3ud7mAkw7ylQtNs8Qia8ZCc6TH/p1FbDRR3Htfi c4lTPvcUPTSBRl5a4O6ZX8BRl2iHeorHYfETIkV49ND8nfE+bfdU3fexq5y2vNMRhCDoCbJL e4mwm4NU+k3n54wD2GFekyHh7S0RVOXVy3SqVSiC2OfbcemKbJG1OhYYolXbF9CPoInPbB5c 16nAo8em32lkXiAFaGQWjRDsr2fKejvyWNvSk9DGFahWtDO/YTCov+KEyC5ORe39zgzpau2V d0hqbqGZ++RrakFe+xWijRFkkU/EvmK1IK/9iidNECQI+aTmPrr9ukmq63rt7A5i5PJXuNfz GhUXzu9Fdfabu8jkldm1IejpiaBGrHL1784tg+ghvEN9Do+jjfLFh+6MWX77HusXxwoHBkkn PkMPMjyq+G5n7rtUJMqEGtHMfYo8B8mqxoIiuTRzn6anWuVozh8Ed2vpCwZlmN9t8UfGfcY6 jNMv2LZ0UnYJ/xGySbjgf4WEfzU+qVPRTllIXo9z+JzsBI1ibJY/LItoqF3/ctQhru38ha98 iR+iwAX6G5n748l5l2xkd/2gdMm7sBeDQzA1bWnp4Ye+F5QNqgla1Ev9vM19ZbNAqXAms/Vs ZpnlCQGl5J6YSgSDG49Pu6DPt4vfJs8krNjtFLNcnHUMbbk88FSDfhmKT0q2MjcQsSx2jKSW llDtk49nup3zDgkTobefy0DI8XoUSwkluKQw823aJf6YPsyVYk93uw1HvGxDL7C28FSymra7 tGasbxWSV49gcCMxkWgTA8sT8Yu46pEhp12ir/ktuFf6E5r7sxjcoLu+mqyqpbT3gtEOz3HT F+KzLLbMHMLgxjJLHhnxCGlG3g26zVL4s7Do4GM/Csst19yvuWpu6sLP72x0qtiFdRiL1cU1 VFwyXW8hmPpRTGWpjpSztgc2jKWE6sakJD/Or5U0Pqq5f+shOiJGQtxVN/yiw3zzbngm3Isu n8pe/pdMNHM/ouR3DztbSUFFQbd4wZ9+Pu5a5ZVR4rFCcx/B4JBsarpdSkLdvUI6XErhjpG1 p8oGFzF8mc39FSsxNkJHUWq9RFZE9UQuy5JzUlIyj1I7M1pY+TrTT+6QoreETc6C6yXNKsBt J1eEZ87L5Z8nM5pX0xYee82LVlpkvpuz5i5ueyWf6nh6WLmlttpRbjOlTIQhvwWCwQ1jcNc0 pHwNfW6dwiHz5j43n4DSGXMMS0Wvk67ki2x3sM98fpa1De9t7tf3YyrTpAVNJdXR5guuAgf/ LLn9AhrxD8OqEcydZ2eyIjn3hrnldGSwFF6Ua29q+sMKzP0arLG+7wnltFDWx6FGMbhq3WMG ak7nfJgeqngVcSpacuf+zaY30Ff732flUPTO5r6bspK36VWE4Zj79rOX03m2ejlnt6fgEAyO kHzpnPSP/NIOCSYLhtHOOUxLQVUomhBza/mH77+zuZ9x9WlUCmO9GfqGFny7T8injy382gPt 4yorLLxL+/LJezO5C4tKPGVt63zE62Ueo8t8rw9z+YzEPkFBA7q5H+EkL63pKGK3YPeOyHFz Vj+imm6V0M6Ybv3Dmfs9vg5+Wrp+ZlcR5twMgxhcscpBMQmmO/eR3JvPY7JuMrbQzNJekpfz YMDkqTKWkt/J3M+/M5iYc803jlbgBbdTMeL7BcTMc5i+VCirCw4+KSnlqReNdaTu3l6J9adu zzLvBggG9w7mfum9mDDnnw6edsfgM1leKqv0cA/mEQjzvTfNcA2SMbh8WS7BI7InTdIXrp8Z DG7AWVVSSsNJ3nfBDIamuekcPWx12ylvGMz9twjM/XdTAL7J+v5NveJimqQCrQ7JcvHnIehl +7OMwilFOG4/wrNZUkk8e/52eyaNPVFJcj7IJyZBvVXf+wlWwl/uJ54ojyYC9TRYurlv/bLL 8kkm79bte05WuLaOLDT3FYOUBehtHvHub7Zg6JReyS3zB6/RrOcCLak6ubPuB7YqHmcoSjkz WUhH4HD8bXeaKTM3F0Z8alZbzjiM8p6qO42Nj59pZC5wSXN/LgwZMktzFgn0V6lifdV/dsYk JUjj5h3nHkq9M6HPYnfaBsiHlTA9l9B8XT3Fao/3Q3T36IpncGlzv7FYIiGQ1y6Code3LGue regJCQQ9/EjrVsT+w+Euz4mspiTxjsr1ixrpDymtss515/VxkjnHmqIzaGbKMd9wm1eMNqYF jQy7TdYLyZgqXbzliiDo4Q6b+54cIp46Fx/6IAi6p9EmR5Ej4AbN3LfIkv//9xkrF9Z6sVTd Vqqa5bTXvhrdNcLa4DeY+6HTk95FRpttnYR8MhjXg15xsV5xrvwl559lwiyvP2UywZYy9x0r 08Ttju12KdYrLGYtM839kLevROjdAGQuFBkyTbEXDgpSrWEpYcx94qmY8pa9XstPqNvbZHNR 73v3yy73CYFPLog7H/36H5sPnXno+WrSF1coH6HLHdmGJi24rD6guW8ZqBhVxnSxNF5RSbbd 5/cITRxbovHM6zngVthhL5MD1okL5uWyTrHPduMg9ZgK5rvdCeb1WYd3btjgkuf6hPDW8ts1 07338gtyh1ejSYtcdIGPz0lHGey0r0bjF7zakHYE7SvogGVyL4farO64cnDzCQRfd3jDEVuh CGJ1KeB4oINYFENfbt13aOpZ3hSvTO9s7qNcTmnlP2X8vWt1mlywjnDR/PfHjrfOitoJ7XEr 1itasLxTXbg9/U9E3HvD16hvVCiCuFWliIR7CPklMXwK1Nj+9pKhqE7jO2m8vwgcS8vSZF0S xUpoTyFbM8mSAfQIw83oFHNf9cRBk1PGv7+xdoeKZEEbsT36FzzxQyEIgp7oNa/M5xfYsie2 0vPFMBpB0P3N5iU2a6SclMPTF6zGHInYIF4RK8NnhMApph7Z59vtVlc4ZJZrt+JZoyXURSOI 3x839CP0aBlotygZ73eKMyh55DoyQb0mKeb+1s0HD/0kwpCrVmj/9wekf6aZ+wtO6WFWtXaY zyER33mD/lOa+/hKc0zIVu3slys09xWd96w56q5VtsiHWnDnA4M4yXW6oSoJhQtmMEHwtOdh 8XjPbobnCD+SuX/TfxfHgUOnan1eLviGFUHQVHP/ey1Ppez5UwTRCIJG2tTOxEgb0c85XJYC SS/sH5Yxdlkuxv+I0LoDiS99Ole6Mt+qv4+5X98ZHRcuuZXjgO1vnnmUZGvNpwvz5XeyH9a/ YJO7WILZz9vc13WKV09i+iWzud91MuGkxE//+Obb/7J9x/GfNQu0VWyT1vXUqvHlNxIfk3JW YRfHf9fNF/XNZsEf5bOjsT30rL8Uc18pSg39B+vbKxqSEv22SWT557zG5Oc6a/P+f//6f+y9 ZVxbabu+/e797mc/Mp3pVDN1V0opVgrFHYJLcJfgDsEhBEhwt+AaWFWatrhrSzptpzadeqe4 u7P+H+IhFZjKzOzF7/hCcuX2tQLnfa/r/PGHTexauOXkUQlv8wvkxwue+buh1OXtDErBTxeC v6K4Pw+Q7tmpCp/c/sN/fmTbF9hGYYxp3K8A6W3mNbzoRoRR4p1VMvq7mPXl3L+cY6wqvu1f G79nW+8W2An1ePM8EOgYAUowElK+Wj4NSayFvMlkNdRl4HOJ+yQQuHk7xRexc9ceatv2/3RY USHqt4jKuaI16vsM4j6IT4230hXYyQvfuUHfIP1B/M0/JO6zkHuhztdYZPMGOdXEn6NWN/Lz ifsW5sanXR6y8SxNDTB0TYKHvyyuex1lw3dk/0///mEbu4k+uHGLgV7W4/i1Vb1Q0vYoPg8j tG3vDtpluHn7xo0b/rHTSIlV3PeSl41edWR+FiDdRcJdTAOuhJBAqrhvpeVM/pWR4axr1drH EdZ5D2JZ3/rD4n77IFAcLMpxbPN3m993IfA6tPlcBoFrTfE+hv+Uyg9a7SFx48Y6c+5fztR3 SFBybWX7rr+ZgREqx+Ua44u/R8blawvZO7TMfKy/n8Qni/tYA6NYFJNdAYu4/zLtYrTgP7/f +sMWtsO45cDZoza3I69PrbmRnybuFzcNBaEcpbk2M1S6bcP3O7fsUVTJZivuh1lYepm8R2TH BTjr6RrJx4ElTAL0DED62UpOWd2OLu77m57nOfj9v354z937uAMC18W4I/X5xP0qpI6HolKC N+u20AxA+tmKOec+oXU0FhukIX6UcWq+/+GHTbs4eNcl7hM6ZjLKmq0ktx7cw3hL2fLv/z3I Y1rI+sQAsSXWU3PLth3UsAO7TmoqJbyNrp4vZtH3PyruX62ND7DeY852Ib3FRmQjRJ0dOxay 6C+OAKQSFWmMFaY9hU2BMwDpjqU019FtG9/7/SsebZf2AhL3PwAk7n8MLAiGTY3YFvtwqhz5 DgbbQOU/m37YfuyPi/sg7vVlSXyUlHsF+6qfA+KeZhynbXRptmwPb6olW+//LwWt9mcBlMOS jOI+GNjzWD9c4J86IUjiI48WVnFfPURTOH8BN7SCA0Ec+MLq5xgOSo82//OHDf/YevKQ2WXc 69E19qJTNc1q9z/+82+G8dnKJcaP/QVHTVGCW14Mmx72JTjukef8D+Mw/vjdj4I66xD3w8HH Kj7WEvbBxk8+1jxazv3020yvfx1xHwS9SRdlnHhpXd6wjfuEhIdh7yB6ZjF8eY01Pr2hkmi+ R4uAezXygbBwEDRN8FYIDTH+ddW7y4thjxJOBCYbZtxes7hfqP7/G6e6sJyeBkFcfxviKoZL i8Bm5bxH3EcvzNnGK23l2/mvH7dtYFgPVHZuhGmqAK3eTEV9RNy3JSbwiv/jfzfCNmxfXSBs wzE5AdsCT3A5DHyk7GUh4YQxWTU4/vOzCIc159zHgSBu6o3TnZDdVpnu9U/dm7KE9Xb/8z/f bzctcevqQV6NlzaXkL7K7hGfzyju+6cYZ5GYXl+XuB8Ogq5lHscV9v7vD1vZzQtsA0xWLJDA LJv22dy+LMuF0Hvx+8dS3LzUz0mBG/havCfAqyVHNdRAogzEja1+txWekyBvgGcaq4kX9h3+ Oy1yvJpefbDeN8aEQE4eei++41EX9rkSMDgZtrj8RQx1aXyauE/OuW96k2krjkXct7kSxS32 geWtKOhYvI7MPDgQtK9IPafMUNRhSV6zFHu62/Ajozr/g//1r39tZXupwrbxyQnFPMSNMOxM k8V931RTVnN4ZgbatLLcj2/W1HnYHbwEhr+rV0u2P7Ld3IRmhNB73zIT/v/t+ek/m9lWfWD3 ITl4xe909wKquC8RE6ld+wdmjVHcZ8G/vVDLUnTDdk2Fxz1eFOfWT0vL87pMM8iX0wjvyFbc X2wwCPfnl0UbfS5xf2kBOzPqPzpNTe7/fnG/u96mNOTQ+sV9/QABntx3/m/Yv6vqeuS/d2z7 bst2djPIcfCEg8nbQfpO0hcS95vTRQRCnbtH3/eYTvDUCDJCnCetyo5pL2qd4j4WBMNmxh2v xwnoHmf6a2fLps3btvEkQuL+H+HKswGgujHIU3/3//z3vzbQvGp/+nHz5n//z3/9L4+vTsRj Nv9//uXF/TQ1jnMKuF/QF7vTK1ZRNYBvmFlPgmDSEqF9Mq+6O4NaVFzmJWc94Z18wXTX308X 9x2sNslnR118yaaFFb2ZtaMFneQEwX8JcV9DyQBnnsNutCu602vG89sWvpS4b+guqJIcWNGd yq7qzPqJgo4/h7h/a57QPJRRSWtbV1Q+VnT3QVG7Zu9La1uHjOJ+KZGIslPZuWn/Tg1i0KUR wmcV90s7Z7OvdCEltst41nldXhXw1cV9Pv1Eo6h77NZYT3rFUH77wnsca9/Hg7Bob7GDp/ld nwaVUIu69jA9xeOcsJf2X07cF3FRdbkcxvYCWrp2zwAAIABJREFUrOjOapor6oTE/Y+K+6mC /4TrRDag2Y1hRmVfZuP8e0XbD/Bp4n6wvaqgrLGYfTlDpV1+gSGKPO87uf/ZxH1FkxBE7Hvu 3lUjea3zjFfWNxH3k0JspKX1zxpmBTO0LRQXpy/LcTZkPeJ+SlaZOfz09+IJ3lm/UAt8kV5R pS8mp2y3Sty/NVfSPJhBr7oTm4EW2rpb1LkrgCUn3rcR9+WVzJOQ+e+ZwdqJgvZFSNz/AJC4 /zEwIOicY75Xw1AMlWvf3e1LxbQkQlz/i4v7HtdDOJX3/c8/vvs3zZYNtvXfP3733X/950z0 z16vyJFM4n740rjXaLWQOg+/bz4inVXcV/SFcwX9Qk3psxg6PxFA6RFRDucpwONgMDyNW1xe Yy86VdOCBM/Y6jKMj19vf+D4PG5phRIz/MLpotkPpzUlEwFbaoxPd7d1lhOvm+3fW9wPn58O HumjjYzvLzc1UmyP7JVQuPrcf62L528k7tvFKx10Q2vmdfkyLBsGBtHTc0zOEJ8g7kua8Aul dvs+YVdgz0DgyFTYFxL3l8e9pppF7SOQ9UStIpQA/5a9cgr/4PU2unZdsyBFUd/NZAbErd7I +bOK+7we1uKRLe+Zl4Ggsekwpk/9+cX9Rcz0WEAfvRd2xFRhpPxR2RiXt8N/hrQ8nyjuS5gJ nk/v9n3KfnkHjUyFrauRoTOTQYMMRTUXyqF09h+1M3nZhwZBHPjIqC6ab4OaeuvPHuyWhF/f QNDEAm55hV7mJ4r7S++smpMEOWD8+Od+v4OotlwRd/ghzQJM9zhlx6X3vmWu1j+1Im2v3mK3 FHv8egZYtki/uLgfPjfl1XpJWQXGm/fS7nfyi58m7i82Msn3LLwu1Qz25TTCO5CD/7i43/cw qBS5x77IpOsd7bPsxf3Hly3i7bYYFrz6IuK+lg/PTucSx/rH7Gaw1793hLqHBOLAv4m4HwaC bpf8OAwR/OaJNgz9taosklbdxoOHxP0/wpVnAykpiWYImUPwRIfwS3QzuhjAK8ZbREBX3qwk cLUB5l9b3J/FF5U7awhxu3WFEdd+ynItlDS9Ss6Kl+CQ1w7vwJJTzZDFfSkUPKCVRU5lSsvT 2BKMCeY64eddO5HzkVqmwgN9NRSUBINf535yKqGvm5ZnLNzVRNU8TDPhwyLvTF7lHfNznzct T6ebPQquEmhPBNlkSKBBTsuj+J60PPjgL56Wh91oFNeRcBZSXIgss+Q3a/oso7gPtPVnXrkV mFAVWDaY07IAsIr7LyJiExRPquiWTCTTU6MsAKSXzloqalbJtrTsMYRij5jryEzWXhRUvXCV 3yjtWuPBmmfms6flKVidlieKnJYnZbq0pS8vyU4YHm4Qdof1slo35Zf9/L3OaOUEX5mjL+n2 IaAELSbhi2AV960lhH2srpMzZdGgpeWpjSWBVHFfTcG0wLOKpbp3GdcIUsddnL9IWp5JoLFC X85Iw6nUj7VeZlofp+ZHcnBhUYVvVqXlKXa1Rq7HULeZnJYnh11anhZjcbZpef6c4v50NrHF hGc/PKgj8OZnWmNkPi7uTwGkZiNVJy2HYt/yYYbX30ZEx6vzKaqvXdzPTYt1cPI4578qLU85 a1qerDBrRdMw+eAnn9idzyfu9we4BhkYsU/Lg6Cn5ZkHSC/ctK21HdLsL3TnM+j1SWm5lvD1 ifu/hcamK4o4Gue8zmieo75I3VSwXyXur5qvwopWrPH5k4h82wzmv3w+Ku5XktPyJL4vLY+Q KDawY5HhrQ+L+0sAaSzEVgNuFWeQ+qGtI0jc/wCQuP8RZv3B5ypWZuJRmVZPehj1NfuqDFmz Lyrur2BBkrKfJZ+qiUQKgy1beblxUbqK27nvtWJMq34LBkEWcR8HLmKWR1zTDPabeouauIgz iPshr+u1Mu1PSCR7Pl2V1IW9Ke4n8vHP+r56qG/Hx4m9ZP9ggHZMDwuCbpf8BHzt15eWxyDK gs/SXAlgzTzDyrcW91mZG3a9c1UOwXEYV+P56P2SH1veNWllOhzY44h89O4DKTiwIOhQSE7L wyqR/KG0PAXq/y0XYHbtF1YNdx1peZYW/Bv9jtkHqyc2vc9WYVVRHxH3A++UKWJ0TjixawbD ygkHJ6zx7NPy+Mw9kltfWh5w0W9+QM3BSCXNg8fVnvccXKwFt49DSTbQgycgRFwvjr3b8J9P 3MeCIPrnjPNoLzGnSz6f+qnPJu5T0/K0sEnL8zjnHC5Q3OUqa1qeTxL3V1U09IsBgOHnUlBv ehs0sYYPrpnPJ+4H3i6SD9HjcGvB9a3/fvVJTPRYV2QKix0WufTSvx/EgRP2XVdk6L9+Ap8o 7oOzgS8adf1Et2glWbfcVMf7nJXVkb7YTUvBj5t94/A44iCfk2E56RPzmH0+cX9xFteZonGx wegOq5WB370abe2NZzJe2Lwmv/KJhrpD9vmhElpKZ8pe+jEZ+y7hwNfWcWYChkjuyI5gEAwH QdyjbNVAnxO2JRR/XTLTL4N/DjvJ56Jy/a4XU5PYifs9dwNztTfp4w3a3uBA8APivndVooab KmfSi7djSWsfqw+L+6EDD8wBy90q0bZNz9+fMYiB9Yv7016jP8vBhSUyv7m4v4QBX2sHeEj6 RxoxpbcCXe5UwHW28WRC4v4f4cqzrgAvNwVRTfGIPuYs8wsA6ZG9hpKUeoBexjDrv4LfSNz3 NxU4onnFs3SogAQCpNni5mchgZFmXhe9C17SFPBPEPfBoppHsdFeogq22oFN2GsTjJGZZQ1+ WLxJ7JOC9jWmTq6/F5Za55FA97kFSCDQ+DwzA8d3UlsvihRNFl/IhrrCaieVIkwYg5teJKXn m+q7a8T/Fl87C5B60/JKbWT0hS3zPa70MIlcdXfDYkvtg29gqinpofGEYgc7XS4xH7uciQy6 xDMPkB4HY9Jtg2/4lI6wtPYrG+pmF+dY2rpIGcbb5/QXddBFjZKW0djoKCtsTciFfoAEljT2 x3gbqRjEWSQ+YtApXkalxWvLyhxYj6HuUGJSmpWhtahJvvfVmRx6w8iDk+YS0YK5DgKkRYDU G+HmrWsZoZP4gGFSniemJenKi2/5Y4a65+QD1TC3aa6hyRmFzl6pNri2eKqSiCfUYhIB70sg Qw6HmaKaO2h9fj6jImv82mw2mcR9lndZxf1xfMFFV02l02Y3/K4Mk81OCW3D+EyMnJiBkstF NG2XJS1QW8fwpFaiQ05/cSd1Btv6s0ouKp6T1sF2YVnls896cl/t/H5BV0m3ytCbFL/Z4ubh 2KgIZQ0jbdRlzHUQuDUNVDYgjR0UjaLMkx9mMV6DDW9ycksN7EsDr/Vlranq4jwPB4f9WlcT WxeKSSBATuodi9PXkdx/yk6NRdy3NOU/qiRuVuhLM9QlzRQ2PAj2c9SwLnbLfE031BWT4+cz V/GqCq2hqZ/j+MvVnu7usmY3MeVfwlB3ESD14Pw8EXqeql7VoTWMUulofl27u0OYS/qruBoQ II3kVNSbyerAPa8FXBqkl1Be7+diJnBWZl2Gus8jAiMM9AIUEp4W0d1HZgrr7wb76suqJFrG PlllqPt5xf3fXGR2C1oXuRSRezQHkB4GBqWY+Vz2yH1LDfsUcR8sbvw9GqujoOGJ8O8Mu8FY yzj+UrOPf6Jl6luKOe2aqLubGOu17wjSOvlZagsIkEBCyzA+I93aLdkh+V5sAwiQxgBSqdp5 Sy2naxialWstKSQyRllOjeu4ouraxX2goiEIHSSqEexUvJDVQn5xJK+yzk1H+/Q+JkNd4Go1 0gEloR9imfiUwCBJE1qG8Bnp1oFEf8Jbxq0grL+3loaeWMhv1G2D7mTCdXvHOJ3we2m1a9tN T0/PtLdylbapiOhcoqb1H8mrrnWz0zkN46Ya6pI1d2V1xwI3+qQ8j0gsMlBSE+B+T859Uztp hXCHy1SL4Io7kfF4fbc0Z8JSVgsIkG4HhoWJnnJ2uL6QRTHy7ckGLlva2p09xC9uxSTupxfd RCdd9b3M4DZMmi642RqkzXnG+IJj7iBT1QUZzlbIw8qFtB7lXLsbgsbp2BCCbw5lk0CgtTuj oFRDUlM9tC2MyYz3OS4cq6frI+fekbraUPe94j4IkMCs/FQTS2dZ83Tn/IHSLvojiUUNfdE4 jDm2EXtlCBL3PwAk7n+EKR/wjoS6vERsmQP9P8ZnFsR8UWPlUxJfUtxfWcY+Sz5lYiZsk2Y3 wPzW9O8ud322ndNTTK7xGANXifsgbmUF+1uFiKf1KeFThxQFaeI+bup3u/ZiUTUNgbQq7xfD TGWO1cjjPM9+MXHf47c7KmrbTiXXez0jK1PzwcvvLEuTxUxEDyJM2Yn7hRxi6rI4oks3ZTTC n1Wp58VrFN5wfA7iyI81dCaJ+uqfM8JaPABxNIdJcDpw+b5+Rrx6SYPbr2M48BuK+ytYcMC+ jmhV0eTOtFCHnB5ekhHnOBXfgnq2xqqn3to25gqLip4OLXFg2G3CgmDA41q9omydrBpPis/t BflYHym3DIceEEfLST016Hm3RMDGRDTpkuOTsbWK+/YFat8Jq3HZJ5s1PaXLuKOPLa+kyfui 1erWYqi7shTW36GE8xFyDNK6SGLS96cGve+VysaVkg1XGYqKP+dtf9a2lJZ7xOfpLaPcSJWw C679YxgQxA3+anotkVtDRy6j1p/hyQYsCPo/qtG9UGJ4iRRAGZxs+VgfKa9Ljr20wZny7unU jrc8cHzTOgx1cSAYsjDnGGdw1lFhO9z8rF6s5VyXuCLPaVWhPYYeEt6V7DcwPkXc74jm2SWj QnxFyT0yNeB9lyATi0XcuI/qAXHgZxb3cSCIG3mgXxQtbGovl97ox3gYfHkx7OlN1ZxS06q7 vkwf+WziPm7giXF54lmEgWH9u+BRhnoHOnSxXgLeEVo1z5niPyrukz9bXmff+htT2wbv6BOC TnPp6t7qDp5h/sjbDsPLaTLocOXwDOsnoyEz72nqJ9LXrFnoeYLX2fp2H7ko9Mg7x+pk2chk 0+anfuRMTZ8m7uMGHhtfTeDW0pfPbAh8Q39EBguC/g+rdC4QjK4ypgv/FJbCwF9NL1bYVN9l ctGYfGNxI1WQm1em6jV51fn3/WKUr8lp4qtJeMBkiwqOuN6pMMjNNGrqxU0zeNV+qrgP4iaf 27WhdpxGqIQ6cjgjeRUCLJi8eSf9pm4hbM15XKP0au4xN/K1Y9c1bWwm8tcxDMMcfT5xf34K dxXJZ2p60qfQmNGqePK1W1XmORl5+bpud8oa/URxH/R/dNMozuqUjrNEdqvb2zEcCOLAubDZ F7YF3gKKilwOUZq0jYTh+2YpwYJGdrLNfYEUF+DJwN8qTbxl9mmn6LW9Zr7S1i/uBz2oQER6 nnMPtnw4MzCfuvax+rC4j5sb8nhKFDM3PheIt+pg1vf7H9nUlqpFXXEbZbjJzI4HXrXaaeyn mtHqR51Q99YyjdRkvaImFDUs8Fa+IsaEx63Zb3AmHARxk68cbxdLelsc2n9aJOGbi/sLaPAX BQcjCd94i1e0F1/bNF+QtjE6xbuNJxUS99fJUkVNT3pUaYCKnBzHIQUx1E3X5AfJtZPFJJDQ PJhVVueXeF1PkZ/rnDy3cbFf9rOsjkX85VvYdLKTXgnKTOrQefPzxkmoOCIq7gYqrjO2epQs +pR2zGaUVKNTiKg4Iio4xl5H9DtuJy23PFQcERVX7ZtyL6V9YbW/30cpuHEvHGXFwa2j7Jru EEdExZW6hmFlzkufVQi1iL+XQVogtPcnZlc5GslJqtuIutGcbIfSL3V5umDgfKeEHIrtMl8m 184CpKnCepKrkZ4Uwl/bI5/RYs7aAaWoaSXm0Z7bskaN5kqeiT6S67y7OaN3a0i6k4Ull1am R+nvlO2H1kEg0kRKUfvoOQtxBIZu9BocZ24bIGp6MbJphqJi1P6aGRMkLGgC98BbM5rg+aG1 dOykTVPd6KfRX8bnpmpJKIqZlyExjO5/ocpwfQn9VKuMXrKxbRqhFZNERMURPcLzzeHHj0s7 y9oXoOKIqPgKVNrD5LrJYhIIkBZK2voTsioDE4n2tpZy0uJ7lZOdI66i4oiouKqg3AeJTTRx cDyn8mFYHNE7joiKI5oZaIsLC542J7qS/YQzSNgrQ9Tx6Y6IjtfTMjtvnOwWdZXWF/fwIh1V WWFTvGv2a4AEAp2TwLVSMy1nZfMIU3qXY/SMDLkP8+zefvqsPcEh61VK3VrsEOp+xkWGyUjp yTtfsKP7J19ExWGUFfXgyDK3Mmokodje1ltCN5RhUmLNzPRO83Fv/h8BYZsE+8LfEutAQvt0 RnFlcDIRFUdEBUbaIMT+dcYZQVlFNX5p91M6FotptbeNAlnRSmLawnpBBjQjX20tMVEjuP3F MKqSGIlGIRSEzlhQhy6OiIojuIZi4ZJqmsF3Mdc/fR1OZV696+OBkueFHdcrMUPXhJa9Tm8F gdvzQONvkVm1fsFobQOTfUJBrhFtFBfc6kf4mGBBSSctnzyHOCIqjuiBKzYz0BDVjLRKfEA/ BZ8WqKEks/2MrrBJsntUOaWRYZlOTh4CWjk+F3oY1b2sSx3h6URUYIQ1QvyfXC46ngWouMaQ wud41rPbH2YJII2nFjd72ZupK4ryqQXziDpp+eaTG+kWVqCjIn3eLNsth/5YQ3pyrLGhnaRe mEUc0Yu2ftApDqbmnGJoW8Kr1DXUDgJXawO8vM+IORhFUlyOnf3j9DRk+XiObt6tcE43xb3o OZ5y8rfWztFR4IS0sLS+nMslexxlBl0wkXAJW/PEJzEUQXYcIJVpwvXOccmKqTqroogeMeTI PKR7iLJKgG3ZDJ58hr11uOBqh2/CdVQcERUXb2BswrFNEY69SO57QPad6CqwlKzYNr5NL22m rhmMorgmL4+FJnUBBxc9T6Jtz9ysdHNxk1V1UUURPWNpyyzfCY0S51dRD/ol9AYIkMCSxr6k UCcpHR8tlyz6PcfFDS4vsucY/9ZjVoYRVRjiSM6qDbwP3hur/QNC+LSw7tG0a7/EJSRMUVxF K+QBRSW/PQc0Po3IrPWNyzWzdBU+DleKuORIDk5sDMh7kXNreY1ZlSgU1r5GO0pzS1orI9NQ cURUXBkqzktGXJtXKdoo+jG13nxduIm4hCUipSHsxlJ+Owg0vEkrvWDn73x8J0LDtdgXeJvR CpJNgO1NDOU1gzQ8mIxtrV1R8vIW0oGPE6pm1tzIphcZGXHypwTOm6UYYoioOKJ7aJ6ZmjS/ uJFKQG1INUg+uW+vbaSICNYKoFbqE6CmpXHixJk9O/kEnC95lAzjm0GANF3U/ByXcN0vjmii ayQjqylFn+5GTPHLTPpZ9cGk3HwLbTVRqyu2YZR16BjkI8ard/oQjzhDWh6ABCYkpZsYG/Nr 4zxjymm9dg/LN9NTFdGMsU17zLgNk5AUr4dQPy4T6BFNDo4zsbXi4zHhQdbG3hhb28jU3AoN xsqJ22tFX3WmDrVjkIcYr+j+zQdPyrhp4m6Hlw+Vdj33cdRR0vVTprv+RiH0zHiOcB3Yt/eI wRU7/Nu0+jmGkn/2c0fKSegJWlEHx80HoaZyUskOkbaQ1ggCpN+iEuI0hTUlXK/aRxBRcURU aIa9rRWfiOjerQc5ZN0R0Xdjqslp8UCsn72GohSfFeNlVeIcjFEQVdYKfYxlecjjcoWPnT0X t45S9FUnsuuva4i8mBivcIjTxXfpJBAggcX1vydh7ORMsfreRQxrLFJb11XFLN/rOnUXoeF1 KqEJFUdAxXkKnDGUM4yypQXnPE2unmSo9/ewMJy2lpWYWapX7DW6mXZIjjZcVMi80LvwHSTu f4C/jLi/hAHH3LoaLCqJJsRieIoP565dnN7J2sVEE2IFsqELNUZVBOZHfd/dsyQSTYhpAjoK nAo6EmlUQ7PqW+6/9r73ACx7ZgPAZ4hQDV6nIMUYmjFahJCD6aHTnLtOHj7lQbRqfYceXasD LRg6M+7zpN6k+oZJjt9pB3Mu9WATItGE2O7xeiAEBEOmRj1uXzMOU9ssqnhazw9R3eDwZAw3 u4QDZ/zePbGvLdEod9976NRJHZRqaa1Ve4P+tThOQR5Oc5RSTq1d8yN/8tltwIdDZtuGn07Q xX0QDB58aZGH3G/rq5nAbGSajRP18JJwzXZcU0coHrmpAnYGHHRD3SbnX14HMUf6dj/WwYgc RAZrJRWbEIkmxAs65XFCJrpHeA9vOyd5xinfpusdbpo2jOO+i3WyZhInjf3kY4kmRKLJtXLj IPNjBsr8filmd2jFPjG5HiGC0D4fzGgyWapdHsitqX3Wt8i2cyB0Zsz7cZ1xtu0ePRtx+3Sy ky0WBP1f3rMlBIs6wvfrJJheuO3T895/+9kx4vXqLpI6dFJI6ZPqcEE0tQFN970p2WlWwsFH yj4m/JoGkmmMRoLZShm+guJ2Og2/B63Ow/4xggZeWOYiTxg4yEZn6DJaE2Pd+E0sJN1yqDPY b1Ofq+hiIRlPNLlIDSPkqgcZH7RPsWp/Fjw34vO2Q+9K7Omz8kK+YfodD7xfvXbs9NkuaCjl m2ZJeur36olDofqPFmHqabXuT/swA08cC9S2qSOOyFmJoSK16CsHKxKIUYi4STvoHdT30qmN +m6U9SF99RNaIdR2Njs/eENeG1gQ9G7Nk/G3FbAIUGNcioRc9QCjg1oB+nX3meS8x+Wy/jac 0kYy1EhFnB+fqtRZdSzydT/5gKTP24faIcoHLby0kvKYnAyxbvx2LgqRFdRGPjYuj5UwsJRK IJpcorj4qmYG8ygq7Ny/YY+Gq1xGp8uTNRquLs2H1qGOafBuFLGQjP45eGHWAi2yR2DndkVn xQL6KdSQ4beud6me0tnep4y0T4jZq1PaWW1/5zf/ScZif7e/nykqduKoXaZ2FtGESDQpylJ1 U92loSSWWu/yDAydHvV+WG2YidytYyvphLdve0LZvXjxs21RgLCD8kG9RNNLXb69Y2tK2OL3 uFYz2oZbzUW5sNSQNozlV4ywdieNPZUzqz1BELeyHD7xwv5WoxmxUCHWl/uAiFhmHsVw9WYt sulp8BQ1q9LidNDwI6vaSlNilpizLZ84QpbRu/XnN4ySn/ebu3oYSd7gPN18Wr1XjVK8uS38 1cj1kh8v6H5k31FlAmTCo3U2yzhr4LLJwWbXbyLv94SMU+8kS3MhD2OP6pkLmgRpMznQRkv5 OPI7FXv2jTOODBYE/a4HnlTe99//3r7zlKluY0/wHzzXP/rQojyM76zQmZA83RKiCZGok5Mq YSpxSMVMpeyW1yCInhhyb79oEKy409RVKuyq089vyJ7PXg879eKcBIwkTnvfMKt/ETI8jQNB 79e/aKFVDpmjECn5tL4YE4mqYc58dm7w2KpPftiCzEIIWH5Ox0hA3UWZcXAKk2QD3c9pR9p0 D1O/LkdQ05Uylqp8jpGqTLeyLDmMyzlzF3jJC9z4Ag4EQ4beuP5cY1J+ST/FfCfCVsolgRxp SiRadj3zZ7PPNOI5flNEUviMDA9M3UbYd1UXFmdDOlP4bWyF3EPVWBoZYM+n5aLX0R88CeLA ucDhV471ROPrRFVPFU4LM+FQWnC1w93n/lNrGRmauM+tKrVd1kIgmMFuuCBRPcyP04VgNzCB BkHc3FDgq1azUiw/10lOm2D58rtOb6ewSwvo5x12pT6Cetr7pFxVK1oc+2aCF0AcOOL7+Ia6 lcpBTSf5RLJHcJnhhUhBVblT+sFKl+8wbpp5twHaAUan3BJ1gcsmRKIJsUA7LUBIQ1sgtdPx 9SQOBHGzY2Gvb1lW3TQh4sRNdI9y64kTiQa0duYn6LqKfaeVZtD2BjfR4/+YaFDifHS7GK93 JONka4Q6nfcOkSy+Hw/OjIGfLO4vh4MTng86rKqIiIwIMd1jh1zydHLIRd60rGzx6JsJo+4o h8xOOl/y5UbaSwTEMl2D+AgJVySvXoxN3yj9r7KF6aCOJE6ELp+NN7mZhkSipLM+l7KuTGAJ 3erjdatmutdxESOVQoIRkWhSkCjjb3lYTm7XngMctiGa1+55vZ3CLS2E9t63bK42IaaI4+w5 jhmp5JcakauuarK724ObI2+azAYMvbK5SVAw5zxkF6KY0+X+dBC3vBg2/ty2nSBma8Uvq69Y UeX0cib0U/f5FjHgK4M05DlHF+kwWn/jxHysj/Kc3bVv42HbHKPKFwEDs3/oxsKOv724P3Ol 5oaGpPgRiqnatkMbT/khs59lksC8yy1B5gK7du2ivLVLcLdYYnDdpK+bocQZtp5s+zZu0UOk 3I0jgQAJLGro9dbj5DzMNpJz5xEXu+qxjHXJNEX13d56nKcOUUrbvPvUEYvG0KvjZOEsv7rO VOTEkV2wjVtgGw/L7De4mdk4C5DaPJzMzlAbsF8j0zaLnk4a46ovwcXUwl3iXmoRr9bRNuBa mbWB8n6W/u4S2iOehK6fop91JYv79qWWqBQfKwWGYBEupQQfEljMWGbHGADEKwkL7GIqVknK 7VooawPG8qpqTIWPHd5FC9u9ccs56YAOajKKeYD0yMVAiXc/u3nZfngjZ4Bt7otMalEm548y FEU38j0m6WN+ASykbCo8xMUHCG2BbWFr08dtLeHZwdjI9MLrSBkYDEaP2byX64hlS9hVpocn gPJSKz2lffSiuM+aRuihU9U4YNu2wQ5o5tjnrO0kO0B6l3UdL3/g0J4tTIMjE3QLw5Kpo+wC ykKecVLOqPo4XsdL7T+4h+q+W1j7FoU4znGQ7fLm2n3Sw6FhkuXEcXK4i6LwcXqYSKhZ/K+M ATG4UA0h1tK2HzorHDIS86FcIqt5EeTtJH6EYejMCz2IINAxAgCxikL8O6l+jxu3GOjhH1IM Zlv6gVi7czwclE/t5NioUIQGmAc5K9LCN1vCLMlaBrZ9O638M3s4PB1XnSgPcdIW4WTpjii3 eoof64nyDzMHkB466chx74ftP2+lEtmliq1YAAAgAElEQVRXGGknwH2SYl66j+eodTuOOMn6 qdIyTzM5pqp3ixyQSQttnl11Iv7j5AI1viZnt8OoPpnH4Ef0CPkFOAVBvp1bxHg0Uv0o2zO1 do4x6vpRgdfSpfbs302tGnZYSCR0IpZ+apgs7oeZB6Q6R/ue2wLbTLsvCSNVk0G6c/KNziRv 7Z927GJZEpRgEVt6cGmpu6kse5/MLbCTWqlW+Yw9+iU0ypux3o1bDu88oaudN81y7jsJ4yAn dIxe1HE7LbdwG3eTw1v2bNoiKBvyc/jqBzU+MpLV3sb822gjuQUGOyIsEjYVX0uNaR8CyqLl BHh2ru7IHtFDchnhrfPrmEGABAKkWYD0wEFb+sw+epl8jh2+l2n1RtHqhR0RFg2fjq8FAUKx mwltYHkErcu86Htsz/3dbUWPMDXygKidegrI6p766TS9A2Ks+biodwnYyY2nQ5wIb5meNbla YKolv5deqaq8X55tYozySdjmrTA+p06/KyBAepN+KVnqp927Vg/jFnE+Hbw/0wbbSNY1ogHf ngM7KIthF4emTmGnhhhTzn3KDJZWoIz4GTxjYRv3cG+El4ZdHlzVne7oxBilk7DNW6mDI+ag kcKS3P+Tqb+fFOvOAdu1jVLvkd2ntHUKSXqKElz7YD/xGYn4Py3uXAZIDY7mupz0zvIKIgGL sFJzKdjmrbCDOgTXAuZ2VlT7uBgd2gL7kRIvwa+byTQ49feTYt1Pbt9JrZf3AI+7a8ddEw2J 03thB8ScNFMpj0REhvioCLCO9k/HJUSx8wl1bHqUQ7jhacC3edtP1ItLlcOidnWWniAbRUEO xjJ5hWwvejM+L1JS6Gwozf7aF4+2TX3OUmBKZomZJGzTVnrY1kOCx+x+jrk5DUBpeT7IX0bc n/ED78tZiPx0dLUn25HDwmZa90HcNIgDQdzQz8aXXHaztYLk1JdnkCDXQp20uyZDmXzC2HKt ogJhddiPMNg+l0vuP7M+uP9RAnueGISf38C5l6GFP30P01AqaPACQa+X95RMYBuond16WoQP +wuudwYH/m52JZyLj96pn/j596mr76IXws8pG0w5aPb7DflwvX30z1L/2V5Zdsox2y91hHl8 pEU889gnD/kAK8vY2sBDGnysRaEKVhU17bt8T85ECHaE2qmdu/gSHlimYHl1T204JnDU/DKO 4TgqbmU5/LdsXlOprZQyd3wP01AuaUaxFjvk+Ag4LwTbsJdW+74dO0XlL//mNwziQDDg3UO9 UKENp/ZSBkcRYw2CWBC0zHbhkIRtgME2/LTjBz5Xo+v31nLolaSZ63yIvd0obIO0h27hXRwI 4sCVcPCpZrjJoVMsMUePiFtr/8L4tMEaWV4Mq/U/qMrLVKyMpx6lXhrPLW9HnWSM2XfmkFiE CznHyyDJkOBIWzlHED46N353uYPZJ3DyRxgnt3WM+a1nDmXGG7gPb+A0Uoyp8qEd5MdHCDlJ MFQtI+pXxOiw6lCdKaT6nsFZFYx7Vq0ZpbqBpZESkS4vBlbvw3l3ATKODL0W0JUIbWCJCVmc c8g03CN+mHlwvPSL7jFHPrPojGQcnD1CKiIXZvUdRXbwwDYI6EqENa51UkKf4s8Yip/SC9Bt BHFLC6HVvvtVeI6Qf6V14XaZtAPPewbnNI9tvMVz5mKn3jrfDtl39uRGSszxffutjZ++I5/c DXh7XzdEcMPJPRtgsA0wAS7VcCQIhoOgRYbdCXHYBhhsw47dP/J7mFQ+CFrrGhv81Y5gtIHr EL15O3b/yO9pSitqeQHza8YZfbEtqzuyn+ewdLTL6yHKhtnUG6dO9F6+ExtXRx5TOGdXyGwD O+U93Smtx7ftMC1s148wbbVLHTR35XAQdL8azKXNsXoMN+3Zf9jzOuoh9U6yNI/5NeOMnihr I48pnHMoWmU/uxIGLhpF6e7l+Mf3h0UEoh/ghufWNmhsGXhiW2y44fRB6uDwHpGJcXlDyfXv 8aRN3hC24SC5VYqCDkWe4FIo+Kt6oM5+DtgGGGzDrv1btNM8O9+SS0PPTdml6+4SYV7ecr5G pb+svW0LGLBSDAnfyTqM585oRiBZg5dCwV/VAnX2n2QKPmoYot9MD0N1FEnYslne38Nge0wT LOt7VjcDPTthm4bYKXKIpSgmXl+W9NeEMZUpyK0daUOPGbDryjsnCNuwe/VlxcXrmGL1Yi0j 8wok4OancZWekkkXhD185ZSZKj6gHWkCgpR8K/3tDnm2e2Ew8uLeBnc6X/IifGbcLVWbU4R8 8Rz48bCCWFW3G/VRlNDJEXPPs0e5KAX+sO/wHlSV1ZOx1e3wf9iEMIDBDlAiYeI6gkSQvk3R 9yCowGAPx4H33E1gG/Yc3KCDN7n9DvfrdetQJfYx8v6ywAMcCK5N3F/EgE9U/bRYFgO5u7uP KipV9wSx2GZ0JPFZizBFHlc670LwWlV4OAi6XfI5pX6SHqkQYHrhIUuY+y/1svqwDfvJMUI8 ujGGE0MIN57tXLAdSi7qpS9xcxOBN912yXGx6fQpCS4HIm6IfOKh36YjW+AcdeWcN5WPacUt Tgc9TubQPL+ZPPCHTghl/h7I+kDAh+lQibPaT6/0DL8rXr28XlYf9sN+2B6LNGRj7/pvKe/h by/ur1TVzFwpuPWQ7jlZPVbQvlBKAks754ob+/A0b8/KPnztRPHt5aLmoZzq93iyVQzltVFc 9cpuLxU19GZVsQ3rzagaLbi9vJYDvHTIJWdSS86o7M1snKUmCVkuuz2bX9ubWcliijtX2DSc RW0Avn6yoJ2efai4ibVH+NrR3NY1JuQhc2u6oGEQz9Jf6tDRE/vSxP3kF0WNAwzB/Vl1E0Us KYC7loHOidyaPuZiB3KaZopZG7Bcems2v6Yns5Ixsi+nZY6aBHwFIC0UNgxkVbKdl5706rGC jsXS9xZFM/Idoxr5ggBpoaRtLLuiO4NNgd3p1cM5zYyHJcHSjpmCWqbgjMrezMY5epoX9iPZ m90wntcymVvdnVHRja+fKmz/VGsBKkultyZzK3uYh7Evp2W+mCVhRec066TUjxXemsyp7MFT 3XfLbi8W1fdkvmd546tGC1ctb0LraG5ND4OBIdlAmB5Q0jqeV7PKn7OqL7tluWRteasXi5tH cuht68tunCq8RV9I1MHvSa8YyqMZzHYtAW0j2dW91EXbm143VdzJPMjt4wXNUzmNE8wz2Iuv ZtPf4qbBbNYbRX9W/STr8v4IKwBpobB+IKuyG18znNu6VNZKb2RGZV9m4xybvNWsM9idXtmP r50svr2ylqqpK7Zztqihj97fqoHMhumyjvHcmr4Mph6Rxf2iqFuTWQzLbNUM0sT9uvhWpgsH XzOS20a7rEDg1hyzuzLzPYoxuHO6sGGAbVh6RXdm/WRBB2OPFopbR7OZL/yMqqG8jmWWzC2E lpEcxhVbNZLXNF7QPIx/34Wz1pGs6M6o6s9uZai3awnonMip6WNzM6nsx9dNFnetZwZZFhKt TIqB8Kp66a3qYBzYvuzGaQbTjsUipquM/MUxksc4g2vl9hLQOpxFuwYretOrxwspN2Ta2p7K rx9guIkN5jZPFbRN5FZ1Z9B7tFjaOZnD/p68+hpcLr01k1/dTf2u78FXv8vruGMhy0bcL+2c YZnB9Mre9Lpp1hsFCQRISyVtE7lVn2lwbs8T2kYz6T3qwVcP5nXM59X1Z1V2Z9QMZbcslHWt AKTZwsahLHrz+rIbpwtap/Nru9MruvH104UdzO28NVvUNIRnHJwG5sFhrbcPXz1a2DWfX9+f VdmNrx3Ja6f0qKRlLJfN3bs/u3WFbUKk0g7mkawazGycLWPIlkOmuHGA+S7KsghBoGPqvdd+ 7cTqvIKEdspoMH7FZDZRLKAhcf8D/GXE/ZVwcD54uN+vh42rnn//cMg81a9yaR4zPerH1gqy dyh4fCZ8PbXPBo8OMpTZFzQ+EzI1RTYh9B+dDptfWmuZ4UsLmPF+395VJqJTs+EgGL44jx7u 9qV2lsGcdhEzMx7I4Azp19fnP8jUtoCBMYqmtjgTPD7kz2JsC4LYlZWwqWH//h5Wn8zRtfsx rqxgZ8f8B/s+oajl8BWmGfTr7g6cWAidHA8c6vXt6QsYnmEy8l1ZwS5MBQ73+zEODovDKgji wKWwhemgfmaDx+7+4JkFssti+NJCCH2c+wIGxkNBEAuCoVOjAbRP9Y1iZubXsjDmQ6ZG/Nnb jXb7DoyGTJEPDq9gwYWQ8WF/1lnu8e8fDlkAcSvrvRzYDju9XhqMhslUA8P+8TCygeHSPGZ6 hDa8/kNjITOLYfPj/n29vt29gcMTmPmF0Olh394e394h9MRsOE3c73gTNNLP7LDKNN2hs8z+ nKx2rMxrY3E2ZGKQ1WWR1kiWq4bFmrhvKHic9fwjdmUldHKIdXmzGxzM3Djj4Pj3DwZNr4SM 9Pv1kUteo7C7soJdmAwc6g8YGguZo8+RP/nX93WBueOBIxOYReZil2mTQh2cnmHMAmVwwhfn Q8b7aMs7cJCyvDGTI0zLe3Zh9WB+hKWF0Okh317mYWQsitpfNh3p6fMfmKDP4PJi2NwYQxcY I1fbwC6HL88FD/Ux3+qZrn0sCIbNjAUOsiuwu8d/dCZ8YRn34Uayt59dCgV/VfZUgB07cwoR 7zixwHjbXD9LC6FTDCPJPDhhC3PBQ9RbPaVVK1hwAT02RL1v9PgOTYZRThmD2JXl0MkhP9bl PYaZXpUR6+OsYMHZoJGBVV+XlIW0KpixVRQChsaZlvfc1PuWt//wBGaWzRclrUcsRTGxOBM8 Nuj3oUYuhc5PBfWxqde3uzdwZDJ08QPjsIpXIAG3soybHQ2emA4aHQtmup31+Q+OY0CQsriX 5kIZvgz8BkaCphexK8thk4MBlEnq8e0ZCJpdCqPa/mKXlzGjfQH0cezxH50NXWDjYh++MBcy 1E3/yuwfCpoB6fbBSwvYqSF/lkuU+WLwHZrEzC/hFmZCxwfZxwyMBU8v4NYq7pMXw+Cqr7Zu isvx7BKWxT98biJwmPky7BkMGp1e/bWLBcGw6bEAxqub3fIOW5ilXzjdfYFDE5jlpZDRPr/e br/BUfT0Im5lOXxm1G+A3V2itz9wZAa3tExZOXNT9L+p+oeDJ+ZwK8vYhcmAQUqD/Xp6gyYX w5fWdHHNoSeGGf5I6A0cnUTPUNrsPzwZOrfmPxo/yt9e3AdrasCaK88G1ilGQKwPmrj/wWT3 EBAQfx3I4j4h5iN5h2jiPmO+fgiIPw0tfUCmr9B5K1Xf6sjWL18dxJ8GSNz/AH8ZcR8CAuKb wpKCHwLib8byPOZNIbc27z5RE4Wc15/k/wnxt+QVSPj2jfi6rE3ch/gzAon7EJ+bvJtPwoNQ +vJnDp7V5lH2RDgkGwe3JbXOrzqGDwEB8VegYwIALtl72/ILyJ3g1JZDhmojk9wLf09tWRXZ 8CY7J0vfXvfkUSkeMXM4EmfoXuRPnM/t+AKtgoD4NIobB2Iiwiyc0AgkGoFEIyz9ERpWcg4E j5I3uV++dog/D5C4/wEgcR8CAuJj+Px22zjFUUDz5AYJo/M2KJkIvAGLCy4ExF+c0IUZz3K7 XbJSfMhE6+dfvDqIPy+QuA/xFwQS9yE+N1mX2lGWcEFxOI8wnEcYziNlLcLooAsBAfHXonUY yIpU19KnXNHCqjzCVoZ0B10Gqh+mR/kJSqhQI7WFlANsaA66EBDfgsKaN2gHdWk56leSuB6P eo7/lf68b90wiK8MJO5/AEjch4CA+BhuXUQlFPw4nIqO83rtKyAg/qRgFmZdrwTw+kXrA13Q xtX/aSBxH+IvCCTuQ0BAQEBAQEBA/K2BxP0PAIn7EBAQEBAQEBBkIHEf4i8IJO5DQEBAQEBA QED8rYHE/Q8AifsQEBAQEBAQEGQgcR/iLwgk7kNAQEBAQEBAQPytgcT9DwCJ+xAQEBAQEBAQ ZCBxH+IvyFcU96v7Xl3rfv5NuPhg6pv/VwkBAQEBAQEBAfFNuPRo/BP/aKyY6vzmajsk7kNA QEBAQEBAfBNGwPRmsPX/FO1g4ywY981HHuIP8BXF/Wv3v/2/dhAQEBAQEBAQEBDvg9j/5Jur 7ZC4DwEBAQEBAQEBAQHxaUDiPgQEBAQEBAQEBAQJBCBx/yM/kLgPAQEBAQEBAQEB8acCEvch ICAgICAgICAgSCAAifsf+YHEfQgICAgICAgICIg/FZC4DwEBAQEBAQEBAUECAUjc/8gPJO5D QEBAQEBAQEBA/KmAxH0ICAiIPxPJ6fnO2EtuOW++eUu+HpV3YxJLjb1uRLQvFHyOAgmto3h8 BjKI6Ff8Jveb9w4CAuIvBSTuf/AHEvchICAgICAgICAg/lRA4j4ExAdoeZtU0uofV+2Xej+l Y6Hom7cH4kMsA6Tx1JKWkCSifxYpqgok3P7mTVoPAZYSPOK6gs4t37wlX4+iXGeE2o97bZGN 05mfo8Di2peR1twHuawUA5qTv1IvxrJvPgiNI3rHEVFxRL/cR7EV099+YP8yzBe39MTjbwQk EIOLXyTXf5Facq8/iM4kouLoBGTfja4GS7u+efc/Hy2D+VfaveOJqNS7sTdGCr95e/6aQOL+ B38gcR8CAgICAgICAgLiTwUk7n8dupaBtrG8lpnCjqWvX3tJ81hBy3TRra9T3RKhfSqvphdf 1YuvHs1rnSMwvFvaPlXQ0I+v7MVX9mY3TeU1juVW95J/xVf2ZjVMFnQsld6ayq3uy6S82Iev Hs5vX6aqtKvfHcxvHc+un8gnV9S1DLSN5dT208pcxUh++wLh07tTXmqlp7jn+6Nbdlpa1Y5n fJPF8/lZKGmfzqubKrm9UvbtG/MZmQNID510Fbh2fPfTGW3pGLCgYx2FLBHaZwrqxopuL5d+ o46gHTVFlG2kUJ3vjemcKW6dyGlZKOta+dZj/pkoLfU0M917GuXUNJP1OQosrnsT4yJ9WtRd M7Qz9Sv14n5olPe5LbDNW2Dff/evrULuStiXX20Ay24tFjUMFrQtlHy2Da3F4ubJgqapYhL4 Ve4SI1nXiIb8+/Zu/tchlQSTnC9QRfsEGuUoxfnj91tgG6kcEHNQTwFLvtKX42dhobhtOq9+ qqTrPXdvYkucl8aWbZv+udtMDd2W8lXbtgKQFgobBrOrV3/z9mfWjhd1rVBuqrcXCG1jWVWM AX34ypGCjkWWb+eS1vG82vd9m/fia8fyWuaZ2nBrjtAyjKeVXDOc1TRT1jWT3zBZ2DZfSlou vTWTX9ubSQ6oHclpWSzrWiG0jubW9uEre/HV/fj6mZJby5C4/8EfSNyHgICAgICAgICA+FMB iftfh9ZhIMFF1fOqXXbf168d4+Zp7ZfrTvw61fUmZKZrcO6AwXZsOo5UC2YSF/B4vJU696at OzZt3cFrm6Vs6C51bAf5101bd5xQjzfL7c6+maVw+OheyouHdxzR1MwcSWoil8Dy7pEdB2U0 0eizilhDckWtQ0C8s/DZ07QymTm4aauhbvovcZ/enVvTBQ0PgsNSlc9Y2tf/bcT9h9j0fEWp VGzTTP63b8xnhCwtDQR52mtqrFvc74lLu2gk4+XW/HmOkK+D4qbB7LqRnOa598aUAQHBOCHf X/Pbv8Fm4Rehc7qocRhfPVp4e+Wz7KmU3V4saRrIqmXdX/ySzBe3jmZXdKdXdIc4a8oYob+m uJ9f+dpLU9o08V54zecq83mAR6KFDd6fBH6VAVwuvTWTX9ONcVbTdMn5IuI+PlxV1YZPLyOo ojutoju9oju9ohtfO5LXBpb9lU7u3wtJyFWGZ0V2LrE/lX9rjtD8IqMiVU4iyPxri/szAOmB vYYk1/7VX758h/gDXTsWc8iR9fcTY9w5ftq9nR5wdNNWU+PC50nMZUZifFXOsf0237Fp645N /M7wwDtMbSA2x3ppbdm+ixJwUuOU5WXC7cs6GnGOUXfSSMOZV68a8Ow+sHPHpq07dp41FQv4 jXB7JRGNlBY8vmnrjk37+DcpX8BdHYbE/Q/+QOI+BAQEBAQEBAQExJ8KSNz/OrQOApGm0g4E i7Ser197kI2ViVuyw9WvU91sfk0nJtyW8/uDsO0HuY1T7Mtob/WEBrgonPxx655Th7SL7DJf RJbcDQ4IQUgf/0k6VN+HEFjwNKF2prj1RUTSDV8fJ0lJrZPnPS2TWiNr5gs6QYD0Mj43CyGt p+BYahte7hVT7hWT74z2kDxzavsBc0Xv+iQSCLQMAJEmwgh/Gbs8r5hy15AsNb6NXCpBKp7l XjElTkFYkb1axul3otfWo3cxyUVavH8ncf8uJilVjC8S0zCd9+0b8/mJRKP0EesW999FJxRq 8SMdmqbw37oj76U4z9vb97TLw/y2xW/fGIhVJPgbwc0xX1Pcz7v5wkWGSzfqdkj15yrzKcou 3MAoFvWVxH0K8b56ep55X0LcTw+xUND3l/W/m/+VnkX4QnQFRiVLCcdjOxbf704xCpAIqrIY y68t7i8BpLHkgnp3pL6ktOxh9WT36KteMeVeMeVemDQ7G1d+sVDni+/SSSDQMVpw825Q3DVU TLmxtuJZfo6fzpsLbN8p5U8KuslUJtbPT09TSwpV7hlT7hUTLHdeje+stWZMuWdMuZe3rbA2 RsmzgxackJRuoad3XsnHOPqqa0y5V0y5o0+UjqY8nygP7IgdIrQjhTRf3PwyLj0ezs13Du6u ibsVXj5R1rVScK0LGxGsqqK1n8vZOPdNRvM8JO5/8AcS9yEgICAgICAgICD+VPwfE/dL26cy s3PtPLEIJBqBRCPsIhChXWGJhLC8W2img+196ZeqHJFoXXIYEm3sR/C6CBZ1UgOa3uXnFxk7 hiHcLngXdMYwBBsGX/cmDNOLqn4Qn5yFsEAhZM8cPKvNo+yBoJaJQGa74h8y/+/NWi/CIcko uDWpda6YGlPSOh4XE2PlgjYMvu6d9SCP3AwkGoGMMg++EVINFlPTMuTdfBKOQRvYocX5ec8I wQX00PSqUYBL1muWwSlpHY+LibZyocToOUU6FXS5+F4PZG3kR3mbfSNDbJO0mCDnaXUPSe/7 mSSwlAQC164gzSy5T/BLyImfDRzCVYAACcwFavzMhQ6Z16MvjzEVciXXxMRXWLswmiYtVdUE BHgc5UZ5AOPZ7eSwscK6BncD+eOnbJQYxH1J+zLL9B6ABBbUvHFX2ibjUuFaBgKkkdyKep1T elaZ6xf3Y0queQVG0obRNvVZLMs52abnSTmAGRKtQxtq10zTuF8L29cnwo4VNHR6OGONkGiE 90XX7NeEtvHMzCwbj3AEEm3sD6AugsXUhBJF1c8TEhIN7ENozdNzTnAqnMY300qbB0iPgjFp 5khbSUWl/TtlJc381ZmCZ8jBlKLsQhCBtSEXBgASCHRMARcuO/pEI5BofVSBfU5/cecyU712 IQhknH3inej6sYL6Dg8nrBESjXDOd0h8QJ79nJJyz8BIhGuWWczdousNngEJhuR6XRJp9TLw MiqVgEQyrFjnfIckSlEMYYsAqS8iJsvWiRwWikAmuRe89fReh7i/CJB6I2KybJzc5RQ1OHbx nTX3U6HWrusYa578Oq2e5Sj9UGLOVRdXeiON0BW+ZSPrvTuNZ15p9fZA69qgEUg0wpudoW7H BABctveOQmiqi4iIwgTt1S2DqLXHGXlej2ibZ9X76n7GRGcb04bR7bI7jhCYdtUxt7/k1vI6 2llU/Vt8QoK+HXWZOaSaYjpSOxaL6TGLAKk3IjrTxonh3fJ6/7AkBBKt6xRvnvI6nTqShNZR PB6PdA8nd+GDhrqj+XXt7o5hhpSO5JjH3i2+Ue/hF2+IjLLEVIfWgIQuECCBGSXVPv7U/rpf ZmOo2/A6O6dQ3w6DcL/sV3IrqvSmA/WCNQqp8gdG2dTrQK0XiUbYRiK8qnE3Rz5g/Ps5xf3y Or/QJPqFENTggS0OSbrsc5liKZFRXOXjh1Y3dBE89NMpWWtJYzRjcOilQcbSyMEM30HRlqHV YTWMSednCusfB/mGmdg7CZ+VPs0lL4xEa1Pj9b2LnfIGCLfoyaAILcP4jHRrygxSsEt/HV+7 zv5SxP20npwLRCs7jB5lHnMtE58yr9gFgNSLi8xAOjF2J9cj72kac4G51+5h0GhdG7SCKOcR bqnjMq60eKvoW2E3mBtQ/yoru0DXlnYXjTPxrmA+I89Qr2OaWVhn2q2lkqt1vphEBBKt65xo nvp7RiM1UUzbGFB2wdYrknFwTKPvRt2YWvvIzAKkhwGBSWZIpLgs/OBeBWmrIA3avLilOROW slroi5Yi7nvl+eIJprT+xtwOv8FaclFjfwwu1Jw+jKEIZLJnSU9ay1pbSCc1NsTE3IrX8xF9 ylq7M3KLNHhF1WMfhtYxBNd2OZtaSyvbKIZfsZeAndIvdcwdYiwK6xdibu1jeoG8RCutEe6K Kone5O2Zi2kIu0R1mrh/tcbZE61oHG6K6Ui/vVxCAgESWFjxKDo8UEvyxOajSLXQjhQSCJBm ANIdS2m4ukMx0+OM18vdXH1PiyViby0VQDn3P/IDifsQEBAQEBAQEBAQfyr+D4n7s/m1LyIT S62MEeLScB5hOI8wnFtE7YS8r6qsoKJljG4GNbLl92TCBXs3Z2FuOO95cqQ0v4KptGOVT/FA dvMCQAKB2qfZcX4iMud2HtMQ1nUxoAefOyluJo4sj6ykpvG91hgW4MYjJMtzYvfW/dx7OKXJ VfMIw3mE3fXCmhmE5qms8pte3oz1wnmEEQKyKENsM656lJxBpbhpEONmKC909KiQ/lltnJOZ /hlxZS5hOA+3GJ+ouVTAvbgWiu9r1qV2lCVcUBx+ZN/e3QdP7eeD06vWDNfBPWD6D7+hNz69 RF9dTlhcjkcYziMsxyshKWzufGqPviKyNHhtQ/02+0am2CYdI0c7CX1LXpVIryqw+DaYHemq rGZ9UsLVyUpcCL12cf/CBZSzxXsz/K0AACAASURBVHaRUH9gMq+NGtY5BVwrM3PId0i4jyd9 QXFf47SBYfoFEwdbeQUlHmE4j7A8jzAvn2asadRviXSpYjAtu8TBzJxhiuFc4oY8mpGuifeS 6yaL11YvCJAGcqvLjeW0hHm5dp8z5TXMi4gvsTTUEpOG8wiL8CoiJd2ep7UuEkgg0Ph7Qlq+ vpbSWVFa1bK8EnBhc8Ax41VK3Sz5EgBIrU4W9tLCIsc4Tm3eeOLoOXkuajsF5M21EyeS6kGA BBYQ74SjjAXPHt9yHm0U+RAggUDbKJAVraltwMN95qSQ5innB7mtlO2KAuKdcG8LQQnlI3u5 hbQDjeKvOYd4Swio8gvCOQV0xI1TUFVg8W0wIyXeBCF1mEcSJhrg5ewkB9fiEYbznBPlPnuO U++6Z/EwdcOGbIqbbWFmKci4YoWNJHSjkWn3k+k68kxxy9OIpFQ9DSNhepiSpGUaXFlLRnGt 4v4CQHrp7+aqJCt1guPMjh/37heU56QWyydjLBXwS1wlzR91ESB1x+eWWJnbSzDMNQ/cRcHl YmBp37p086HkwgsWqvCzInCeU0dgfBZsDHVbh4GsKHUtfR5urkOHDn9/QJRLSJFau4mIWopv yyxdyL49DzQ+jcTiENoGDMNoKS4hcV5F97TLw4K1p/TJu/EoFBenp6XER19mOoIKfkaRbRG1 49QUT/MA6YWfq4uSrMhRHsV9PCFumVdRnm5KqpqnhGW5xZROKhf4X+wnB5c09iWHOSsqa/AI ixw9dn7PXlsbtoa6bf34K5WeaJQ4vwq/IJxHGM4lYcSn7ufuY8F9lPfgEXlxqyyP6xSxOzE1 y1IPziMkw8N9dPMhS5XVhrrVD9KjUOfE+X46qi1u5Kbn5Hieh9wXgRMSVjIOFdFVYCk9c31f 9s3LBlLq5+ljqMYjbK/lSwwq7815z0B9HnG/cwaouIPxQcFVNU9Ra+eQdRcRPCetZCAXR9ls TkzJtNSDc52VOLD1h50nhI8KMCxI40KPvLeMZZKDGdaDkpCaq0ZAQyhxKZ9yAU7kVbY56qiL S4gf2nds166Th4Th3NR4Qe0g7Zg3DIrtUDbhpoWBuogUrUAFHmERIYNU85h1+gnH++rp2WKU XUsd7JD8osqUXovon1YL98h5RctVRWgbSi9MMtAyEGa8AHl1ZayS7PIfJzXTM+3gCXXu5nA+ EfjJwzu37TkGOy5Ji5dzLfe8QK+6qPq3hES8nYkeh4jSGXLMOfVz4o6a0TXo66M5lPGZA0jP fZ0cFWWEj3DDD/BjPHPKUR4uiioap4RlucVUTyoXBV0ZLCCBQMdYwdXmYBtTYRnV04yNVA/W D2mMLF/rLuAUQGqyM7KSFBY+cuLU1s0cx88rnvl/7N1nXFTX3j78+//cNeecxIhGg733DiK9 SpEOI0jvvfeOdJDeexs6s+m9DKBUAXeiyUk96cVg7wqiZp4XzMAMIILlKOHi830TZs1aa6+9 ZwzX7Fk/Vp/8ijaa6ePp5yYb3ybIMhUxSyUFUxUDI9bQ4vwng7RDL8a2Ty1O6bk/krPLNRXF BMXk2K8KKYtsu6yfXrqs8SzhPskobv0m0myfrN9Fr6qploW5Icqy5sLahSFdPyaFqO4Tc9MO Hsrsm2ow/3A/J8SUYp+mmXB1+nx6rhBZYYrG2TaZ32STDIT7CPcBAAAAAP5ylk64P/hzbEqM 9O4tq07k+pUy98Yp7bke56Z0ZMfKTTJBWpmMiT27i8uyjCiah0Q8jCsYhcxb9a8k5qRTeLZt O1XlU36ddWv8Q4KsOqV6YtfKgweFJhv3u9loCx1UEz0zntfHVutyHtvylPVf8nbzVVPxMJka l0G0fprpb7hhjYZK3HAkezHejGBDFZEVm2U+Fk8O6LxfQDIIotrLWGflWkOT5lvpnDUV57Mt Tzq1xvz4qq3GZ4Oq7xIkgyDvFLR3Ggnv3L5WQdK5NnRhq80K9xMrTT2tFSVVRULu5XTf8zJV kKQ4SlrlBJiLC79EuN92LsjbZPfGfXzOX5wuY5XLa7+a1/d0qoZk3w0iwUHRrc4m9yoxPdy/ Q23rMxSytstfyJ77JIMgf49NKVTaKskrvppbPtgo/hvW2W/QlxUSlA3VSro/UXOypKfJ1tRX XiHZh2RM5vjUqnN+ppLc+52NM79JG1zQuGyq8wzs3Pbwqsvs37NSviCAdoUgv4jIoJ6QTA0/ +7CAHCsuKHC0dd6k15I7tVH7nfzWdkOhHYfVkizSfynl6HAe2/Kcv0WUhkjoZlpMhPuTSgp9 vLzZw/1Jpy0MdZRFjkoprN6hQcm9m9zDyMpId/XwVU5mhezNrT6eBmvWHNjwoZ5+5hcJJIM4 93VGkvf+lfulvPoDWhgEyaANPyrr6TFX0z9pV8SRvNAID2O9tTttTJpuZQw9I0hG+eD36bQz ItybRKy7WWnRA4Js0DsuvOVv76068Aa35aEN3yk+m6MuJCCommJKnfp9TESwqpzkRvXi1I6x slepa5rmr2zoP0u4P3UW5rEtz8ANojRIbJ++nCPb6zc7UlNe4OPDpwS8v1lwuD9wL8TPTea4 9HaD1oL+ceYvmwaTPfU/XqGqnHAhavrXUz4Jik/i32wsL/HxBl5rSuhgGnk7r/Gc/jEL++Kv E6f3/0lQWITIBmub2cL90tp6d2uDndu1NPMfpPYwCJKRT7R7G/Ov2L1r5SZzjZnxPckgBq4T JYGi4j6asz5K3iVImrqc1M4Vhw5LBppXMUqHGQTZ7WisJnRU73j0k+LB51cq7r5MxJoe2qYq 6lQT9JxCrK8n3D/3GxGhtVvARSmwf7ImcHKIjazgzs2iNqopjBK295OX3Zbns+AwJ6G1e474 3Yltm/aJ1Au35Rkvre6IcDXhUqaFTH0/YJQg/2mncVzwhKdq+NcvUYw3wUdbU0l8636t9Yd9 HPvGckkGQTLScgkT+X0fiCf4lf5RMsQghsbyaoatZNfIeZ/3rWF7em2h0clTR4/76BeOlg1P P4MJPtonTMKUz/w0+9BDDxOjgk8qKG+WyzozueNN1+fJsZ57Vx6W8uwLaHrM+bWhCwHRifxb DBQkVq3nsdU8cyGdvJVT16XLa2pf/l0S+bS0dSg6zGv7kTC38t9y2Z4YYK0oIGsq5dZdNPhy e/3Pe1ueA3vX/U3wsFa2H/MLT9/5OhrKy5vKRo8xF2doNJNKOBor77b9JKZ58ssEdwiy5pQI n5BqinH2aNlLbWE0S7g/PF7Y+GmA7sETAZd8mP8r8owgH0W5nBRUcZP2JSfGVT8scVw/37Fm 6q0pKjjW2jHcsnq2cL+GauCao+1PTrT0NRBUtk4xLXjh9CbCfTlF0zSrQrbavEVUK0uXfQj3 5/WDcB8AAAAA4J2ydML9iqoAP6+95l0xDbeLWSk5bfhpac/1M576Wg6JWpkMghwnyK+cdQ3V DWPMi24XTP3t/bRs4HJGRQWFR0ojqJeVnjwkyKpTojw8Il6U+MnGY0XUXA9n572OX+X0jE+N Po9wPzXSxdg18VQi+7gMYuhx+dmfs9IDNTxbXNmL8WYEa0gqbRQ8bdNxjzr8jEYyiMGHyZm1 xtKSGrnXE7s5ep5nuG8pu/aYz+8RzRN/jT+jDY8W0P/Ibr2W1/1ogbecT4b7g2cK8pyMdD/i jwjMjZA4qiNtUeRU1PqS4f7QWEnPT0mlJSeP7tyyhllPb9UWXuGg6zFtrGddeEr038rveTQR XHKG+8/Kh8YK6LeKzo8vcAvp32NTYuV3rNukTbgX/s6KNZ8R5KOCzhpLA+8T8ikTaX6Is52R S4p1yb1itkCkfHC0uPWrzADDU+GfelQtaFw21XkGauJb96pJBY8ktj4oGXxKkOOlAw/yO+6X DD+jkX0uHgkU7fzAs6OlU5HWs/Kh0QL6H+6mQfZRdWEcHb6hcF/u2BHx/RrZgW3X8waelQ0z ygfuF/XcyZ+sV9nc6uNosGmVhGzkTzEd42UkgxgeL277KtDwqLxPv1sFgyAZpWd/j3OVVvZo cyx6UMSenA4+LG7sj4kLknC8EFN/nyAZ1Mr2QAcFIfdvgmvGWPtlPSPIRwUdg05mmpKibzDc L6T/5Km5Udq20p56n32I0r67ccm5BvJHpMLvxL3K1uevMdwX9TjpczZp6pd3qZ1XMttv5PaM 0y48P7+eVXYUxcRfyLYp++zo1HOHxsravsz00TqolWqS/C/Op3wSFO50+MPtm7SrfYp+o/aN lTFfgzdnew3OFe7HhMaamzppZd/I6X828alJ+eAotZ70Nzq86YC54kuH+0f38UiFaCffKZx8 985JdXLyOuz2TdH553/yMfyQ6O81llFVtqa6NM7e5nWG+0qxejFfTC5XWe+tPPofWR238jnL wL5suP84u5Bw0hHdZHYhomHaXjEvDPc/C03MlJeI8mq5kzc4uVx/EuR4Ude1AM8MG7f0lyjG m+CjLSpKOaRdENR+p/ACs7py2cDDTFqP+XFuOe/zfjUMorE/OcRxh2FTUOWtYvZPTAcfFHSd 9YinyhvSS2ecwReE+7VFBvo+x/WowZ33Sy78yXwDHx4v6/ouO8Vd+HiwfsQFzg1/LgQE2x3m 2r1Jt96v+Hdq3+My8ln54GhB+82iwfEy8nJMYpHecUfzphvpg0/YPxUo6b4WE5Hi4J1qydpY aYHmH+7rqViV+p69z/r36ElxVbmjV9hR/Y7SiU3VWtq8gmMFtMszukbZbrF/RpCPqPQBR48c c6/GxNcV7nd9nhTtt+t9Je3sr+OYp+wOQdZq8B4/rp9nX/V4YlwPbX7Rk74n436b7Kq0915h 913WK5Qz3B98UNDzgNrL3ATJ14Ci61noXPfC6U2E+wd3rPrw71xstXm5lv99Fd9asaRwhPsv /kG4DwAAAADwTlky4X5qQrSFoY5A8N3c3uk7ZhQ2XUqu/TGxg0GQowTZqq/upeNYEzF9w9nx 4rPf+WkLKPt0uTEj2ocEWXVKwU7dsiKIfX/hstLT3h677D5faLgf5nRSUmD/2gNKPKKchE/w 8Oxac8RVPXBoKm3MCNYz9RO0785k24U8nUq3kRelZF1LOMfR83zC/eKu7+LTIlRkKAKT40rp 8Fg0R9TcmONZzzEZ7pMx5z4LDw8X3CGuqC2+TtBd/fRAMkF/yXCfZBDkeGn/lcTsZv+EiYK6 pU6h4YrHKQIG1JklBIjp4f5L+z02JUVlH69ExE8x9HHOh64HeUXoarqZNowXDf3opClzbP+B zUdnnEEhWZ7d69bIJRolz9hFfZ6q8wzMPYS18qNaZ8uDWspMtCjb1hzZIzpjaFGlHRt38Gon WhLsT3lD4b62muFpndTfnluvsrnVx893t3h8eNPDye+mlHT+Gm3Np+DT70owCJJR1P6jN2Xd 3sPCW3lmHIug+MEjPFw80U5Fv+aTNxIz8g0kpOSTbydM3zvifpif00nVNxfu389vHjDgkdBN GA7vnv5oUWVHhIPybrvPwupfZk8SptcS7g8/Js59E+nnp6p6cv/UMhqr+7YFtb3MrDLCLDXt k9Xjb05/aPAm0ZIoq3TGOHiQc8U+CYqNFN5ra1Y0ktn7wpoTc4T7l1wt/dRUwxy7GaVscXZ5 7wg12fqokCvlpcN9KSsNhwaOHcCLcz29fA86f8Ee7hd1/h7sqClzYnINFXhExTau2nfMMM+p fvbDeX3b8pDODrayJ9hfCJ4GMYMzv3s033C/lh7g5cz+sjp0hG/nrj1rDPsj6u9xNn5RuN9B 93Yz3cq1d7ew4uEZbzu7dxw8IGWrWcgoXWB+neCjLaPpMbPsbVnHjxkuYiL2TQ6FtwvKG/0M j/5jk+huPvkZ73iiOw7IbDkc7DcwTp3R81zhfk7wKes4hZnldofuEeeatY87Gwa1RXI85UJA ZITIQUfzsmtZM94MCfLz4FBvfq7NW4QVD85YnAN7D+4RNRIP/fWl9u+ad7gv6m3kfy6B/feN 9W6no45oNZZOfBhTXmBvqLhsDd8RkZn/cEhs2y7Gqxzh0MRej2G+0uKCteQOLtsqMdWzAEVA 0okSff5M133mtHt/J7LtDx8xUfTsiGbtw5MdYnpc0U7EviN99n9EOMN9Tr4GmvrenN/3mt1E uC8pqeKq6lfHrPcbW+fh76uibroLd+7P6wfhPgAAAADAO2XJhPsx4QF6J5XEoxl5fXM0e0iQ VafUww3dO5JnPFrafTXGVkjJu8upnLOxRydH45cN9wOsFaTExfYq+FPMZuNI86T+MLXFc0aw kUu8dPD37D28SrhPkKMlPf8K9A03tGKOqGbie1zdStW22Kvwx+dtLf0cbOE+eTeNSpgI79y8 dec2baoN9Uo+8Srh/vS/0ou7vwj01T/K76jhdXZm1d/XF+6nqx0QV8u8NW1hCZIRFRxrZmSn W/64aPCSjYqskID80VPPOYO+bYHEjO2A56k6z8AxQc6u+7mPamrv3KsmbeavPtvQxhHdwRyR xxsK900M3DMd5rhxsrnVJ+TMfvXa/Km9g6aH+4VtP7icWH5IXI+fMtsaWoRRXFvCG28Wkr/H JKaqHZJSy7qdNCNhjwp6iYK6U6f7ReH+rbymDs3dpyzyLsXNfLShLzXAeKtZf0jN3Ze/5F5L uD+httM3JIFtDW3ldd3UnSq9qhacuib6G+i65ernzHzoLkHSKAphJtNj9E+CEtIk+GNDe0YL Xtz/HOE+3UbP44RsrAfJ4NhdauA6URr03Ph+PuG+fKjp6V6OR2eE+/kNnwf4+QhJURR1XVhr 6E0xsziyjU/U+A2H+ySDIBm5RRUuPuFTZ1DDRkE/QDu0PYxVQHjCvML9uk5fJ095FSNBtjcK JbVTwvyH1hotPNxvavRwMN20XkbC2Edltrcdfb9Kr6oF35ye4KMtbxI6SwR/7lciXFPIusY2 92puSY2b9uEPD5tIaXnO9mYbo+feGDn4tHBGz3OF+ynep5zSZ3v0EUF+ai5rbxzUwLk93YWA mFQp4YTw2UtAXwgI8ji6nI/P2EdxtsXR8iiyz786c++geZh3uC8TYhbUz/HP4rRwvzDTxkD1 g71aaiZ+sy3jGdOQ9lD6S4b7Oiqi3ALW6qaTPcfoezZHDU2VJi5u+ybWfP+GzQK7JM0UJgsO Kwhv2y6+WzXZa/Zx5w73ZTWcsm1e/G899txHuA8AAAAA8BezZML9hOgwfQ2lI95/5PTMsdP0 5J37tbPeue8/88791xfux3jqqZkEKEXP70751x/uT1fWeyMlwkJIyEDOqW7GasyNPdxnFDZe jPC2FJS01In7Z3QXY1q4X1h9NsRaar12Y0AF5x3B5Wm6hj6CupWprK8mUJt/SK34PKl7Wlr0 gCArNQQs1a2JoBkz+Tffue+ur61qmmBS9OAVxnqOucP9llpLMy8pSuppzlubn+/lw/1iarab i9ObC/eLO34O1tslYlVlS7333H5IBjFx5774rHfuPwjzc9J403fuH5HUSxgO75n+aHFVR4Sj yjtx5/7sLvm7msuIGxzzu1I4sLC7hjNCLTUdUp5z537S7Hfuv55w/6Krha+qyhu4c//F4f6d uHSqhojQXsvWyIbbrGajBHnRUl5VzerfEe5P19xqZ6AvIuOolnmvZGgqGp5PuJ8T7qymaCli VRvO9n2vvJI6TxPxDSYDC79zv8fPN/CYgK9721juc2oPvIS57tx3FRexa3IovF1Q2XraUX29 Sm1g9c35bxn3+u/cnyvc/1fYmdgTB3X06sYyXuZdaA6vL9yvLndy8tgpl58y+HThxd7nMmtB XQ7nb2eVNJ06tG6fgPge9mrDwgr79vAdkHZUSpr1k4+5wv1I95MqJtHasX/M+OrYOEH+Hpdz KbH+aj7JQLiPcB8AAAAA4C9nyYT72dlZpvqUVfL5sY13Sqb+4PyTIMeLz93I7byV1/OYIMcJ 8ktnXUN14wTLskdlHDunX82uqTzJIzl9z/2FhPtS5vmGyT9P3nxa2nMrn34tt4u1JW5evJaZ L59FQ/a50XK2P2tpw0/Lem7kdt6h9o1NhSwLC/dNdB3iLInHrN88Lu65ldt+fWqg4bGSvnu5 nfdLJ7bvn3BhjOgfMFfRVjHLcHrxV93ZcYT70x6dFu4TLRfSgkw+kkpwy/uFtXvynwQ5Whjv rWLgx+80MPnE6JBYEx1jStbNrN5nk/k+bfh+WU8BRcT+pH1N2IyxXl+4P7HnfoVX6RVW6vcn QY4WdtVaGnifOJHsTTJKSEZKuAPF1FfW79O83vHyCxxnsPjslZyue4X94y85h7nDffLHAE+/ k0p2mtk3s/qesX348YwgRwu7ruefvc8Zc18MSUoWPRzo2/Ygb6Lx0OPy3pvZbSO53az968/f IogIKa1E07CLxUPMV0rRuRuxEQG6urpvLtwneq8S8ba8lAjNkKH83sfsTy8fHCvpvp7Vcbfo /JNykpFf0R5oryDk8UNo/WPWTegTkxx2sTj1anvuUym8RmYtt9Mn3iiGx8sH7ua2jeScfThx 9gvpP3lqbJC2a3AuGWW/l7x84EFCWoGB/GHJ8Duxb3jPfU93j73WQ9l9zO28y88/Kuy6ktV2 q4C1nT1t+Enx2SvU3jGOTcnJJyXULFsr23XardS+BV6N2ZHqxv4i9m3UAbbd3ofHyzr+leun dUgr1Thpxp77ryfcn9hz30Ur527+IHMTdmLocVHTpdPGr7bn/ovD/U8C45LFj0YEnhujXmAd b//V3LYOAykFJcs3Gu4/Kx8aLey4XtA/zvkdi7HkmBB9AzNeT47CANTm752k96qH9p5unnhh ThQFuZbTcXvydeRnrKXrlmVfPfnKfVLSczslg2qnI7LeeNZwP1hL+4xT75OyC8z6qyU9t3La r+V0Py4dekaQl2OT0k8JKykm/BZDnz7Jou6b+Z23OS6V+WHuua9TFNL1YHLv+7LzjzKJXovj q+W8B3xrGETX5ylJIbt2u1hmfJHSx1nndvBh8blb2R13i1n79bP3POee+4X6+j7SBsVhvU/Y 3r2flPf8lJ/mIXI8aJY99+cK9xlpuWVWJ3n5PH6OaHhcwvHhx5OSntv5Xbfyep8suO4FySDI C6ejEiQFIgK6n1CZ795jZb03s9pGcnsmB5pfuE9eDA6Nktlja9J4LfX8E46PcIYeFp69ldd1 7+Wq/r4w3C9vH4oNtl/znpYh9V/TviWZkRR+SlNr48lq6uDT8ulPnCvcJ2qoBgZ+skYlIV0P StmrJvT/ktOWpnDETtuv8wzJQLiPcB8AAAAA4C9nyYT75QM/RCVESO/ette8i23HjHGC/MrZ QPWomJmY2wAzHCzNMjL2E9eviGe7YzGzpMVWZftO7UqfsuslzBRjweE+7wEtYbuaya/2h7rq SxwWPaiY6E0yikkGMXAvLMj/xHHxzbrN2edGJ59b2n013l2FV8JZJaBv6g/1hYX7ioLSOoIu 51m/6XdzMDmyQ26zbnNO9xhBMoi2nqDgCB6JlJCuB1MxXN9NIsGGT9RWxq0tfmE3Zi4k3B+6 nldXoXZoo5Q93bNycmGbDKT4jskEa6ROpcDRIf7Khz9avoVCyb6VzNqJpfTcSJybtLB+hkny zzPvPXx94X6h0lYJXvGP9xrn2OVdZU2y0UBORFA2VCuRWUG3rO9TD0czcWE1fq+v2bPvoo5f vbT27lcONU745iXn8IJw/0lJTb2HjdGOrRoaObdTpm4nf0CQjfoykuLqiaZU9vYXQ6Jc+Fbu EQ66GTORQTdfSPPTWrd+A4/NOc+JL6ZcuE8MlqkLqcnq5bs1MAjyMUF+6aireHjdB8t3SL/B cP/CU6L/lrupwjFZMynPQfanUys7/cxkuHmDbQt/yiEZ5YPfp9NihNdIqZ6+EEqfaPOYIL90 1JY98PF7qw+8SrgfJb97y3bL/vD6+wTJIM5+lZHidWj9pl0aBQ7UawTJoA3fKe7KUhd2POXW HM723KyMNCN9nY3qRSkdYwvd9IbDPMJ9J52TXNtd7c8+yCEZBMlIp9ZayGxb/bG+Ts5XiRMX f/uPnho7lH17vavZn/vDaTdzBRlt8TOjRecXGCwO3A3xczulbaKSwpj6wODsl2mJAQc/olAS LkRO/+zqtYX7pbV17tZ2+/Z5O3Y/mjheoul8kp/2qr17Vm4y13ij4X6Yr+BaZQ3qw9SJby+d /SI10f3A2jUf/u+WQ3pvNNy/ldvQrn9MSif6Ujid/ffd9kamkqIuOsXjnHfuf+0k/f4m2VDW Ryz3CLJOR0JkB6+dnO+FiTZ+xuKSmh5qMb+ynvW9v5uN6BauZau3chvMui2Pgbig6jHfb4uZ 9Vfpvq5Gu7by77Iejmp8QJBPS1sHowOttn0kqhByKaKDY5IOZjriYnbqqYySBd7Un+Cjrako vpXfcot8dkT/+MQuLmm5hInC/mXi8b4ll4sHGcTweGHzZwEGR3cJumhEDHNk7mWlzobGm4/4 Og+M587oea5wf/BBQmSwvrGtkN+3bB///5JekXF8FY+cZ19A02PObzC8INwvG/g6IT+An2u9 qMMFP46vzX3v52otK6Mv6s8+0PxdOB1oy7eGT+TM48SJchENffEeGitXr+VzmhxonuH+45KK llBzygerjfUKv+P435jaQkN1PSGFMKvql9yWZ+5wP6+kxtVI6r8FMwMrrk77Xkh5bZWjqdWu 3R7O55/M2A9wznB/8EFBVpq5vuU2xZyooWfM/X+6PkuKddmzmuuIcYd7+cRnsQj3Ee4DAAAA APzFLJlwnyBHC+jfn4kv0VGXF5E4waoap8gjKiaoHa8dMhxWfZ3ZsvfXlKRMM22tPaJKRybr y0kbCxlleBb9wYzsO77NTfATlRFcw717/TZZEaM0lwZG8RAjJiJYW+7Iju1b/7FV7qBypkf5 b8y/ToceE62fupsbiUmI75ysdCpmqWiZF0j9NnNq55mvw6OSdE4qHROfKm13RIyy54SPUVBn dP31IpJR0n091NXghNDOX5aBVQAAIABJREFU9Vv2fnRAT9SoMurcoyLy88CQcNlDAptWreA+ KMtv2+BVNrV7Rm5VjaWZId9BQVafgrxKLiecu31L/yiZ+CO/he7varh22e5dAvKHpkrqqfGI 2Kj7twbWXy+a/zp3XoyKCRA7dnDlf69Zt090zwlvNe+zE1vrZKanGBvqHOIV2LFxBddOud2n 8p1yfibI8dL+3xOz0/Q0DUXYyvpJmqZapX6byBYYRYdE6qsI8tt4iRxT4xPkWByLhIspHaNs 0/g8MDhMUVTpsMDxrav/56Mtx7bwKPEoukh4nF/w3cqtHe5uDsf2H9+0VvdUKk3TxEBKSmb6 JKcKcj7Irr3odzpGVU6cT0xxqjihhAaPRqRpzIXEloXtw17Y+GmEt7mQlArP0UPrtuz7aLPQ ZJ8ixhkWWSNTjfuvZte0eQR7SQpMLQ77JJPYq4aSd/KqG72tKLv3Kx/gV+IRVeLhU+bj1ZMP JzwqrmYyPzh5QpCXE3wcFaXlNh9lFhEV1EnUNXJSlxV4f5v8IZVs74rL+eQP8blZJ0WV+ESV dmxcv24rez1hD73I/ljWoJlpiUanjm/fuft9bpFDQgG2pT+mkTdSi6tMFY8f2Pzhqu3CWxWi dFhbAOVU9nv7+KmqcBzIIUkDnpNRTomXUjoflJAMgnxY0vvVmaQwVXkdfv6pSqeCOknSshT+ vWtWHtY7bNEWVX9rgW8Uj6jt/UERtke2Sxw+eoJHVIlH8MRRQRUxB8I+56fUztHJxYmPjNHW 1OOok3ncSsqS6l828hJ1MpPT8y10WV3t37F6/Y7lU6fbQz9qgGN//3O/JsSlaUod2y7KLNe5 X1Rnv/xppzN98fS7E0l6Qet3zrLv7zogsJWXfRklBSh+mkFkdBujfOEfP1Abu/0CvKRFlHgn OxRQ5xezUz/TG84al+i7QeREq2vo8YiK7ty3f8XyvbuEFJgFV5Xcpb2HigZYHwu1f5kR4y8o pTpRB3Xnrt1c723aJCg/cUTiBjFmBaxouP9KVnGdq43VMXEV1oFoCcrY6nkZ7+VzZY/vM1Li DPS1eUSVeIRleY7s5Fqxfc0Oof0T72ailgbJ38aeZRDtX2TEeAlI8nGv2rVhh7yERa57I6Ns mBEV7KMhfWjbtu0fbFc6rJbrWzWST97OrWzystI/yKt8WIhZF5Rf3Ew9MkaMZ9+O7YcOasaY FzBKhxgE+XtEZKyWInNZ9m1ft2r9ztW7pZizVY61Svty5ocWc7qZU1utsXPljv0iO/k5Xghi OtHGsV8kd3OkrmX9NzOKklRk5I7ySvCIKvGInuAR5eE9maQd/MmZWua/BTkVNEszE6FjUlMX w8mAE9q+aqKb/r5RZLcW1aPgN7YJ3M+qptnaGu7fIs4jrMQjqsRzTIZfzkrel+5Lu8n8bO/8 ncKWwYD4YCU5bf5pk9QNM4j6JKZt/tHwvfzWPgctisCetYcUPBRtC6wNdPaJKTOvHFlzUdMc 17yfc1mfC5YPPKBWng1wd1VQYa8XrcQjYiilG2+V8Xnq8LMSkkGQ15Pzy0xUlY6KKu3bvnbV +l0f7z7OamxCCehi38WouO3b0Ig4FTlxXrYOj8kayTq1na66nTfAIEgG0XuNyI5UoejwiIru 2LN/Jde+XZP1hJU95XwvlA5OvvYfFHV/ERGfqKmiJ8xRsVZC4GSARsBgWN298pfZc/92DlHt bk7ZtlvpoIASj6gSz1FlfgEjhega78qbWT0Mou2z1ChPPnHejz/atWGngqRVgUcjo/wCIyMp SpcisXXHnmVrxI+IhDhU/JZBMoje6wVEm6ero+SJkxwFdXm1ZSxTbKhfJvcs6M79MYL8wdvB Tpp35/r1GyYL6oqaU21zJ+vN/BYeHqkuxrtlLdd/rDi8i1f2hGujZxWDIO8TZLeNvoXUMb6t Gzb94++bNwkrKoZ9E9HMIFovpUT6HhVT5hHl37hm66rV+7aJKvGIKqlOPMo+gbM/p6XnWxno 7BFVYp4UATk+kZPizjWeZbeyexhE93cZ2QmyYuJbVq76ePOR3aqhp+J/LR/+MyMpUpcisXXL 9g9WHN4tYqmf/mPWjwj35/hBuA8AAAAA8E5ZQuE+gyAZpX1342KizBw4CsdZJH8T08bZsu3z +ORM9janXHOtsq8UDbC2QTj3WwG1UNcmiGLmTzGLMPKvD2pjlAwzUrKKHN0mKn+GUFyaQuuu sd+ymlda5+4XwVZhtTWAdmXaDIvpPyQmxOtYB0w1swynBA1N5sKlfXfioiNN7f0pZv4U6wRd /56k3rES8sfo9FKLyUqGEefD69hvw7yRnF/r6MhWYTX8bBD7Pafd3yfnlhua+Z/kKF4aSnFp Dqu/Po+7bp/flV2udfylbJJRTjLySqYdflsg8/CfEuRIZEyWpd3EQwEUs3hn6s8pnBuaZ5UN hKeU+Fadd7QN1Z3sxCqCEjyc2DrtntMfo9NKzaeVB3TI0I/9aipYnKfOT0NisvXMonScaiN6 x6IzChxc55okQTKoTV+GBvprWUwNrWETZZj0QyrHxw/zUtz+XUJ8nLZVAGXasZj565zm+PyG IBkEeafw7ICrHdviMCf5y8xJEv1XqFUNFjZBp5gto3Sc6yL6xqaf67ouP7ZyrJap38WVXYxN zGAWtm24UUj+kUY02Zr5a8xSjzHbOfvLyftGc4tr3Hwn6oIGU8yK/GpHssm72TW9ni7+mub+ FDN/ijvhmPPz5NAFNX3BYVGcNaUzDeO+LjrPfgbHCPKL0wHJRmzNLFO/909t9/L2p1idoQST yW1z790/q9uFXQMuNsE6zD5DtR3zferHcgemXRufBEdl6bHP0J1wYjuEBcksafPyfk4pZrNs 55yv0qZdG23fxsfHaVmeZi1OlmHc18Vs+7SU9NyIPRNqYje9N5MzvSGNLzNDgmQQ5N2sqm5P Z38N88kOo3VdG86w37w8cJegEdbuEbMciGOWUfw3zA8USQZx9ufcXKrWbJc3xcxf37fCs5Kt 6m/fSH5FvZlVoOZEA+tkfd+61AJ/Ac5783OLKl3Zy89OCaSYJbgU/pbawyDO/pSbSz1lOTHu GZOglpB2RtkFRnJarp3LxFtfOMW1NaL5VuHMcc2i9dxqz5z/NTAq3dzWX9+3wpNZM/Z6QnaF g8MsB0Ix86c4VfoU/5y/sKV+WNj15WmvYH2rab3F2CR9Gju9zgSDIJ8Q5B8RkWnmtlONrdJ/ iue463/6JE2iBvwLvo6Li9O0OE3x7wytvM7Z5+WU0gabqX8XzpgEt86osDpKkP/08080nDbJ 5IuzTXLO4+384rRnkL6Vv0nUQGjZj9k5+axz5K/lUWSXf7VsaEYUXtvuHRTPsT72VPuUL7Kn 7uy+k1lx1sOZ85821iRtky/GnuXoMK/uYnAA++UdquNS7Nv0JH/yO0D9t4nycku32S5vpxyT xG/LOD7YGyfIPyLOpLKfFIqZv2nU+dCXfw0yiL7LubRaE4vTrGsyRt+jaapWbdcP2dn5GuYT 7wxTRXFzCwln77CJg6KYlZxuvMb8ZsPgfaK109kzWpvjcHJcqd+mLXhu4wT5R3hEyrTj1Q1q 8yMmS1Zcj8+k2bNdhKbRg2FNDIJ8RJCf+/rGs19IVhm/JnQwiK7vs7LzWEc049Fpc5jeOEzX tcSv+Rn1PHPpcsprTcyZS6flWeKQf638wp85BTQn5uIEUcwSXUtGCn5BuD/HD8J9AAAAAIB3 yhIL9wEA4C+grPtyZpShgGyIXvgnzyl9DADwMrAtz5w/CPcBAAAAAN4pCPcBAOBd97R86EF+ 20h260hW60hW60hS2XmrExuOGRdOFEIAAHhdEO7P+YNwHwAAAADgnYJwHwAA3nW/ZtVmyGzY sn4l9/KV3MtXcq/YeHizTo1/+dUits2IAABeHcL9OX8Q7gMAAAAAvFMQ7gMAwLvuYXHP92cS G31i6zxi6zxi6zyT2v2JG/m9C6yiAQDwIgj35/xBuA8AAAAA8E5BuA8AAAAAQDIIhPsv+EG4 DwAAAADwTkG4DwAAAABAMgiE+y/4QbgPAAAAAPBOQbgP8Br8WXHpccWlMQAAAFjUGq9/8dbT doT7AAAAAAAwPwj3AV5ZxWejrY8G2h53AwAAwKLW/rTzraftCPcBAAAAAGB+EO4DvLKKz0bb npx763+cAwAAACwUwn0AAAAAgEUL4T7AK0O4DwAAAIsUwn0AAAAAgEUL4T7AK0O4DwAAAIsU wn0AAAAAgEUL4T7AK0O4DwAAAIsUwn0AAAAAgEUL4T7AK0O4DwAAAIsUwn0AAAAAgEUL4f4b lpJVbKWvdFRa/7jvpzHND97sQHrMgWLf5EB/bTHhAVoUJQGKr1rUz4UDT+f5LIT7AAAAsEgh 3AcAAAAAWLQQ7r+irkvh+YNeOT8/r0FWWaePk6nScYGNBp0BlXfe3EyyyjrdbPREj+5cr08P rHqDAxHkvZy6fwYE1kf3jRb8m1e7/1pB/Tnr6Etprffe0BApGQUW2jJ84sp7HD7P630yz2ch 3AcAAIBFCuE+AAAAAMCihXD/FdUUGDnHS9ucm6tN81BWoP5O8+43Gu4TJCOfoPuZCGwz6XzD 4f7luNSSk4dNbTtvZ/ybV/vsl5kZATvkCoKKL7+5UTJS481N9BDuAwAAwFKAcB8AAAAAYNH6 y4f7F54Rg/epndeyW6/ldtwq6r2Z3T6S1Xojv+dR8eBoUddIdhvzP0vZnlXWf7+gcySrddKV nM47hYMM2gVWm+En5QN3c9uvZOUnnbIIFjOqnqsxK9z3L/mF2nmF1exmwcB42cwJD42XMyc5 4Wp2+52i4WflM1qW9d9jn2TO2fsZpa8U7tOGnxafu5o7OXT7lby+h/kddwqYi/MnQY4Xn7uR 234xMCJNcb+2ccW3UZNH3XY1p3usdOgZq7fJxuzLeCO/Z7R0+vE+Lu+9md3GPITC889ow2OF nVdy2kayWq/ldt0vIRk0kkEMPSo6dyO7qjsqynWLRJJ76iW2bq/l9z4uGWbv9klJ7518jqGv 5Z5ldcWppOdmPn2qZW73WHISwn0AAABYKhDuAwAAAAAsWn/5cH/wHlGRrCIuuG6lyEF+Y5sA nbWbNi9fqSjpVOtW0mYjx71mDffEf4ayPSs+NkZDmHv5ykl7d0p4mVQwCgdZbbr/lZPpx7tl 28fLP3zv7x/8799WzNWYFe7bWFsqie9dvpJ7+crNy1fqaqZeip854daLmae1N27cxOrt4Lpd Ljbtd7JmtIyLiWKf5G7VuFOnXyncL+667KW9f/92ZoerNu8RDioQ5/PUca4LJRkEOU6QXzrr q/BuWf3Bsg//77//9rcVHy9jjb5iw4Ed5j2htZO75Uw2Zl9GxeOu9aHTxm35JMNfe8OGTctX cu9WSzDOv0Nt6zAS2b19HffylaKHlJJ8SEYJySDqaZZ6yptXfLRs2T/+838/fP/D1aw+Nyxf KSB9ejCknb3bHwN9XSV3sg8tekglhdkVpxBnHYlDUy15rLssPBDuAwAAwFKBcB8AAAAAYNH6 y4f7w+NE97+ic4p01SiHNx/ZKe2mFUY42tgpKCrvlDYW1E9yPFNtoaN1wjTiVMYfE0/JzEg1 tfOVtcr0iK1jSTdzdhQXNtRMuJXYyfzMoKT98+CkRi8fJylls0PyYWyNW/xzP0vsZpRN3kve PJThpbx6p/hGEVtVuwyP2DqPKJqHm6us0mmd8N4YttnmldZ72Nvwy7jphhOOE72F5TjY2QlI WevG/zO6a6LZE4L86bSHh4qGA9skMwzM7UV5BHZt37xWt/0lwv2cqvOeVicFtc+YnC7ziK3z iC11DgtVPC64abmsmGV5IMkgyGcEeTettDc4Kd/EylVwy3H5kFIb1lF7Jrb6067l9oyzOpxs XDe1Mj6BlFM20sbprg2M4iHW0P23iuoGfBIbzLWkT2gZCeqHHJdUEDUuswiu83ALMLb0lYj6 Ob//KdH7S3Jpr29Yio211pojTjou+axu6z1iOyLqbuQMTB1LTLibvqW3igvb0AFxRsa2ggo+ lmX3M/ommt0v7LzgpK8lpemn4Ur1iK3ziK3yiE3UOGnIv3/vNp4TCPcBAABgKUC4DwAAAACw aP3lw32m7/zdfeT4T4r798T3jpUUJ+mqqW7md9TOvlIw8DQv1l3bJlQ6+HtieIxo77VzDNB2 LfEsvcn29CvplbU2ZvYyJk0BldcL2Xue35776d6qy3apCVpUBNCuECSDGBol2rpttYzV7PPs GljNui75+4YpqTop+vck9o4x7zHvv1ZYWWOpoy2pn2uV8WMeOfFdhMxTBs4KtqVsk7yRnF9r oa3Js2PVOt22lwj306k1FtLc+x0+C60fJUgGQY6W9Pwr0Dfc0CrLKfOfqRyNX3bP/c5P3a3N paT0VbIYBeenP5oUYKp6QnanhJ2cXYxNwf3MbgbR9llyYZt1zpWi80+ZzV645/75B0RFrbG1 l45/Y1AD2++7v0/Kzde3cJZ2Ho6tv0eQDOLcdzk5UaJyVif9u8PrJr5w8JQgRyJjsrTkhPfz SiDcBwAAgKUA4T4AAAAAwKK1hML9OG1KmBvJKCIZRE2BibGPEKUwhmSUkgwiM8TENU46+Hti 4A6R7yum5HLcINkzvoFTuXNYtCifuXnKpUS2m8TnGe5n+OusUinzLhnhiLODLA1cU7QyWb+h ZRiZB4oaN6SSDI69+AfvE/U5KnJemh4tsSSjvPtqppf8cftKy5yb0wbKLKq3Vdy0xfDl7tzv 8bI+IWVBswhhHXJiqyf15+yzozMazzfcL2r6LDq3lX0ZjfU0peVUJGMY+f2zhPvyUppHdIjQ iZMyqxeF++U9VwsCKYIUHxnbwhlnMN8+xGMvb6Rn/o8FJKO4+myUo8Jeu4shdQ+ndRIfGaSl hjv3AQAAYElAuA8AAAAAsGgh3CfZwv2+m0SU0ZG9W/73HyuWrVg9w9plK45J+fYFs2/vPr9w f2LP/YBKjsx9erifGWLkEi8d/P2MHh4T5Gc2am6GHuWBJKOo4zdXpdXSTk1O5dMHyideZc/9 OwXtnUbCO7evZR3vxzveF4tzzviG2jfGWfj3xeE+bfhpWc+NM97mknxb3mdbw/f/8ffV+58b 7uu7pmlnzTnJF4X7pWcvR9sK7Nry8XsffDTbGdy0bIXOqYzP40lGWn6Vpex6gdPXI1umd5KR ij33AQAAYKlAuA8AAAAAsGgh3CdnhPsqAYpeHRktl2dzJa9nrGSYree/Trj/jDY8WkD/I7uV ebCpVZ/5W0gdFHFUCehb6LY8pd1X49yUjgiayDhVhbItoJ+Hw0nVNx7uH9OJ14m8ONvp+yOj 5QZ1YLwM4T4AAAAAg05HuA8AAAAAsIgh3CfZwv2h+0RrqqKUq7pjY8w8e36N4T4tw8giUNS4 cbZteXI5tuXxfN62PA12iptfbluemcoH71OrizRldZSsCrxa2R96Ybj/oJB+wUpcVd2nwrP+ ehHbQ9EhvnoabzDcL++7QU11EFMK0woezprz6Iqrz0Y6yGNbHgAAAFjiEO4DAAAAACxaCPdJ tnCfHCfILwNtPCgn/dTCe+PZQ/aB64W1bdaOGR7Un1J62HquKTAyduJXTg1uZ0zc0V9QNxQW maLjmO9T+zBnYnf+eYb7nRf9fMLUdE7r5l4tmCwhS94t6upzN9CX0cuxTP+BWVCXyNA0cKG4 c9SMzaaddbHU5t35UgV1e35ILuq0DuxL7XtcMvnLwXtERaayjImCXXlAF3v7y3GpmSr7RKRj v4rpGCVIBtF/rbCm2doh3DRyKKL+PkHeprbRtfbzqQV2BzC3MHpMkF8FhWZQJEX5xF4t3E/x 3LHXyiT2i4mzUN5/Lzsn19o9xSbxQkwXs1KxtbGjvF6kUdLn2SSjfPK5536jUsv17Mr9a/7I JhnEuX/lZEeKnrA1jP4ijm2fpZSsYiN10QNHZy+om1da73E6StMyTs+1/kzfWAHCfQAAAFjk EO4DAAAAACxaf/lwf3ic6P4uOrdET91MTFCfktweVD+aTysw0bM8KOhuntIfTR8rTA0xMHM6 bFDim/tdzvknZeXlDuZOIkoeWvENbpPlWMPznOztBCQsdWI/i2ZPuls7PWysJUR1xDwanGMa POMbbB28VOQUDsp5mJfcSe9lUJu/iYuNtdORWCsboR3QE1N/vYgcLxu4mpTb5qAvJ6lmJerS 4186UjL4lCAZeaV17m6ugvrJzlG1rDKwRc5hfpIC1gbR/2SN+4Qgf/J3tzmp563iMlUw1sLO U1Z4/47Na1ZKhOgETgw071Vqoft7OmzeaqQTWuE0echRNE9rUzGtWIOES5x3wd9IKyk1VRXa JRNh4E3zjG/wDM90tDM4xKckYlPvVXaTIB8UdQ056Ykd14495THRW5VnfKiyos6Bzdu27OE/ aNHuWXItt2ecIEcL6D/EpDd4JzRYaMtIqFmL2k0eET2k/Kf0Xs559v6Sl5+idERYWD9eO6jB M77BLaLEhHKCX0JPwaspgPX1gsy0RGMDG4lTIabxDe6ThxOc7mBsfEAs0LLo+1SSQZD3CzuH nHRPyBsl6vpOLaOBvoHoka2bd/NtUM5wTPospfN+CdsEkgJMJQ5w/cd/cP9jtZl5x91MhPsA AACwyCHcBwAAAABYtP7y4f7gPaIiSVmMf+2K1ctWrF658aDQ6ZGofMJKX2XTii2rt6ioZ95I So7XUxZetlZgnVhSYOf9ApJBtPUE+5htX7Gaa6oW6/41251s2u9kzhyCqPa1kJ+q2rpZ9ahB xeRd/3HRkRpCrId2mCuf7k0l7xa0dxqJ7GaWrt0mvUm3OfvcKDOYLmm1klnN/fHkuFtWb1VV z7yR1D1t3B+D/Fwld0xVi10r7iFjW3ja5NjatWuX7bRQPt2bOv9VausO8jbdtmL1cvbys6u2 LtvnZ5X3ffYsT7mc15J7Yuu29WyTpGTdYpvkI4JsNJCT2slssG7ZCv7jfgMW3hEnhVZzrd+/ 3aw7tPYuQY4kZKer7l296qOZxW8PHzWkujTMGLrvBpHgIMS7jzXJbcv2+Vnn/zB9kkSVl9kJ jg7XCW2QSAk++7BgqtljgvzSSVeRZ9NUs03qubq2oWYqB5et2rZsv/+0nlPCXRREdi1bcXDt LhfbznuTn3kg3AcAAIBFCuE+AAAAAMCi9ZcP9y88Iwbv5XdcyWq5nNFyObN1JLf3aenAw8Kz 17Na/shsvU4deFrWf6+g82pG65Wsjnslw89oJIMYGivpuZnNUYt1JLPtduHws/KZQww+LD53 bapl6/Wcsw9LSQaNZBAko7TvLpXOeqjtZn7vWNlE6dqOEWbp2rZrWWcflQ//OdFb+fnRws7L mWw1YDPbrlMHnpYNTxv3SUnv7by2qRlmddzO635Qcu5KVuvkQPNepVmO93JGyx8Z7XcKB57M csjk0/KhB/ltf2RxTPIZ2yT/JMhHBZ1X2fq8ktc7Vthzl0q/nNk6kn1urGTwGUE+LRu4n9/O frxTC55z9kHR0MwT+pTov5VLH+GY5PkZk5x2UlouZ7Rezeq4zzy/U5McLzp7LaeVbRm7HhR0 3y3sGpm157K+2/kdf2S0jGS13S5iuxgQ7gMAAMAihXAfAAAAAGDR+suH+wBvHsJ9AAAAWKQQ 7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMAAAAALFoI9wFe GcJ9AAAAWKQQ7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMA AAAALFr/xnC/feTn+ss/APz1NFz5tv1p51v/4xwAAABgoRDuAwAAAAAsWv/GcL+b0f3W/3oB AAAAAIBJCPcBAAAAABYthPsAAAAAAEsVwn0AAAAAgEUL4T4AAAAAwFKFcB8AAAAAYNFCuA8A AAAAsFQh3AcAAAAAWLQQ7gMAAAAALFUI9wEAAAAAFi2E+wAAAAAASxXCfQAAAACARQvhPgAA AADAUoVwHwAAAABg0UK4DwAAAACwVCHcBwAAAABYtBDuAwAAAAAsVQj3AQAAAAAWLYT7AAAA AABLFcJ9AAAAAIBFC+E+AAAAAMBShXAfAAAAAGDRQrgPAAAAALBUIdwHAAAAAFi0EO4DAAAA ACxVCPcBAAAAABYthPsAAAAAAEsVwn0AAAAAgEUL4T4AAAAAwFKFcB8AAAAAYNFCuA8AAAAA sFQh3AcAAAAAWLQQ7gMAAAAALFUI9wEAAAAAFi2E+wAAAAAASxXCfQAAAACARQvhPgAAAADA UoVwHwAAAABg0UK4DwAAAACwVCHcBwAAAABYtBDuAwAAAAAsVQj3AQAAAAAWLYT7AAAAAABL FcJ9AAAAAIBFC+E+AAAAAMBShXAfAAAAAGDRQrgPAAAAALBUIdwHAAAAAFi0EO4DAAAAACxV CPcBAAAAABYthPsAAAAAAEsVwn0AAAAAgEUL4T4AAADAa9L+tKttvPsd1/60860v1F9A25Nz 81rwJ+fa/3z7s50Dwn0AAAAAgEUL4T4AAADAa1L/+w8Vn4294xqvf/HWF+ovoPpf1+ez2tXf 3kC4DwAAAAAAbwbCfQAAAIDXpO6XXwiS8Y5ruPr1W1+ov4Cqr+7MZ7WrvrzX/mfHW5/tHBDu AwAAAAAsWgj3AQAAAF4ThPtLB8J9AAAAAAB42xDuAwAAALwmCPeXDoT7AAAAAADwtiHcB3iL nra0PqghrtTUjbW0vvXJwGLS1va0qf4GUXWnofFx29ueDABMQbi/dCDcBwAAAACAtw3hPsBb dDmtJFtu03Y543PZeW99MrCY1FT/Fm51Yq2gm6f3+Yq3PRkAmIJwf+lAuA8AAAAAAG8bwv05 jNXRB2wMHaX5lfinuLn59ha//bnBv0l5eq2NqRG/iK6cQUttwc3X3f+vSUUJQh/8Q+hUW0b2 2z/Yd8blM4EJGjJJFAWkAAAgAElEQVSsF92pgozEX972lOYx54B4DRklmeMWDhH3m6rf+IjV VT8HGvK+t8/M0aWb9rKdlKVVWxsb8ovqKxi2NxTfettrCAuWEZljQFESlzQ1cPuqmXj01ucD dDrC/aUE4T4AAAAAALxtSyfcv1dYdN7fNsjAKMjAYJo4/5ChwhlhXF3jzfggUz4pQyUpZz09 f5asiJh/Em/xQFoe1ubWWjrFGBgEGZgmu7v3EQ1jbXQGnfhnTEQO84isK5NTfqyn3y2rHfKy jDSeOtIQU4Ok8OSfq+rZOqy+FBKSb24QZGB0xtKutbD4RhOdQa/9PS+l2MAslPlE0xQP9z5i cvePpmuF1GZb83AjZrexztZV6Q0XT3s3JsZ9ubCbiGt/z0tmG4iNtXtTauZLp41XsgovRHn0 E6+8Y0kVtT/QzUNKTm6LcE5V+uXXfULvlNYM+JiG+pz5jlbx9i6qd86NtIRqZ3N/vVMuKiL7 /0coJDLgi1fts/l+bU61S9xXpcX339Sc46sMVSlCu7cqud5uoL3xVWpsvJ0bk2HkUpuS9lP9 c5v9GJN4PiXii5rnNKii9ga4uknIyu8Qyq/LGvm3nFxYiKpPAuOHMpJ+fV6DgrQWT1MDaXGJ o6cGGovuvf0JA51Bp7ZnefkGaVqe0bQsC2y6nsue89Z2+IQkaVoGaTkmmaT9Fpte5uoXqWkZ xBRwLrz6el79xZCgIC0r5i91vcscqdfKhv8kSAZB3smsPOfpFnSK9RSjgHyn3AtO1rRw5kC3 qO19ztYhepN9ctJxSXcse5rT+06E+5UXTscNZaX89vZP2UtDuA8AAAAAAG/b0gn3b2Zk1pie UDgmoHDsmMTWTdvWrNi4db/CMT6FY8cMTO0aMsqntR8vqvrGSnQzr05eYvJrv1/7FTTdrUyI l5ITW7Vm25r18qpaFUW1j1rpDHrROS9bkx2b1/zPigNHhAKDQy9V06/nVTboSWkKHVM4uGvv R6tX/335gZ3L10uZ1Gfmj051WN5hZ+twZNdurvfee3+FspPfp+V1DHrlN4kh/nyiqvu3bOBa s23Tbj0trYqiuketdEZDxQ+ZsSW2Ztb8QsrHjikcO6ZwjFdVis/wlJ/z/h06JkZE9oIOp/Kb xGAfHlH+lcs2bFh35MBEh8cUjh1T4D/uYGpVnVVwl976bOELdcn7TLrWwcisqvstr77mNV+c iQ44KFlQ/frDfZhT/Uihv977CnGvIdyvHyn119lhXJEY+wYj7PQEmpnUViX3f0e4Pz8deuax dpSywjnaVH8WGhnII1ZYj3D/HZSXJWWa6GbdP1ebonPBbqZHdQYR7r8rMmmu2jJ7Pnpvxf+9 xycVMRDWNTYZ8uaEmksf3fC/H67nOqAlefqroKAgXYr4ls3b3ufau1NQ/pBhiUfBb1lldBfj E7wiIhtWrvp446FdykGacb+UDj0jyPtZ1W1uHh7HhRWOMEnxKaoJnLTf/v+p6ud+nUAyCPKH VCLu2Ps79x6SPCCscISXf/fWdf9vxaGdPNJHhBUOHOLZc+Aob9DjePo7Ee7npYsZJ3nZnX/7 p+ylIdwHAAAAAIC3bemE++y+87Dz0Zaw8shk0FtmPvq4vv5WJe3buCxCdedhVcvK+IwRGm2E RhshaDcbmsYXfif4s9a2sdqqKwTB7OcVumIpomkYnNZRyU2vHaW3/UmnM+htYw0F53xs9TfJ lxCZ00K6x1mhsScU1fZLZbtJrN6qHBcV8Svn0JcjI+PE1v7X+//4G69aZULKo4lAvJnOyHQ3 F9P2tff8ntmy9VFGSKy8qOjhbc5hlXebJn5Z+21clPfO9dz/998ipxYa7tMZdPqDSnqlDK+l JedzEwJClOXlVAwvtNSPt9MZdDqjpWW0rnpqDWm0K5UVN+ubn7W3Tz7rzzb6aG319Qpap71v pMpev+jc70tZ7SuIq7UNz9rbpk+gufFeddVUtxVVd2trHzbUsPU8Ge4nfVtdfY11Bq/VNTxu ndHbfLU+qq29QTC7Gqmeu6Bu8/3JcWm0EVrVvbqaW3W1t+qbGPT2lxq9bby56W7F1AV5tari dkPzvcq6h81N43MsDq3ydn39Y9YhPKytvUHQrlYRtxoabxGVV2m06zU19xvbnjTUTFzt12tq 7jfTGe10RlP9zcrKEaLyZl39WGvjbaLyKrND4mpF9cO2lqezz/MF4f6fbfTx+tobbAcyQqPd qKsfbWVv1vKoru4GreDzNGf1rVrZIQGfzdWYPt7YdLeKxtYhca26+kFL+5/t00d/0thwu6pi ag1r6h4mxy443J9cHBpthCCuVtc9bmd9msUsmVtxhUYboVXcqKkdpbf/Of2kVNyeraDu0+bW B9XECI1GUPQCjRXSk9mOqLLqdgP7lTMZ7qd+V/W6Lm/6k8Z69sWZuBgeNHM2a+W4VB40tz9r bblfWXmV4DxeOp3R0vyotpp1yhpGW9vGm5ruMM975e2Ghsfs3ba1jNbXsr1eiOvV1Q9aOc7g szb6o5qqa5MDtbf/2dJ4u7LqCo02UlFxrbaR442CeY5Yh0PQRqrr7tVU36ufcUSvzeQBJkQL 64RaG9azreTV6up7Ta1sZ5AV7tfl/DZxCDTalQrarcbmJzMujPHGxmmX98zFWZh2OmNy6ZgX WM292urbdbWck2x93Fh/k+0oRgjiGvvVzjJWV3ezgjZCI65WVj9sb33W2nS/pvoqc9nrH7e2 zji/FTdqakfb2sfra65PvhVMNp64zOprRmgc//5eq2scn355tzysq73O9tynTU33q5kn/UZ9 w7Q3ijnV/dIfGZMgt2nLpl3/WKuUYZX1eynJIC48JQbvuesIix1au0HE4ojblyWDzwiSQTQ1 uLn47BdOCBsYL5yKgx8R5KfmMopqNoUuDaxfDn3uZqkrI2uhksooG5745eXoxDPyO9f8z/9T 1pwM96tzj231dS/+OZtkEHWdMV4G/ylRFFJ5jSAZucXVPpaKfCELDvdbR+vrb1Uwz+/DlpZn bC/JqzV1j9j//Zo8ZWzvOXc43nMmLm/aCC3+jIBWmL1x4/Mu7+bGu9WVE5fK+MSl0sp29qtq HzS1zDIu6/yONzTeqWReJHcaGx+30RmtreMTF0NF9b3G+ods1+SMl9U8VX11hyCflvbfo9JH slonXc3uuFt84c9yhPsAAAAAAPDGIdyf+eiAjYXZfq6Ply1f8d5//fd7f1/x4XJuLi5uLq7N G7h03SMvLXx767vUik4dwb1r1kz08ypdsbQ+rEkq0DV1lDrZTK8dpdMZdKLHxT3oxNGQmIKr zdOj0n4LI2v5I5aOkb9S3bVWCDo7OHVz7ix0OTIyXXP7Xnlzy227zM3M63LpDPqs4X4RQdHz 01bMSCFuN7U9Y+ZBbeNNTSN5tByxQ6bmry/cb2487xYcp8mbmFv1YCJVyUlv0Zfg5lo9uYzb 922h2MfdaqibfNbDKnqTmqTUZq6P/vH+sv/7r/eXLf+Y1Zh760ZeDc+b9cT0CSQEnJE9Ntkn 93Zhr1M6hR5qFPvk240TPU+G+3ZukjLCXFzcXFwb1nEJ6rkOFr70XjpFtJMU5Y1c3Fxc3Nxc 3FJzF9SNjxFnjsvNxcXNJRBmLGdkomNuH8GgN7/U6LVfx5zx3r1u80pmn4f5tlq4J4QeMShK Cf2GvWW8f5g039TicB20srMfZD5aWE5RV9rIdZhvk7GLl/GaQ/u5uMQV5VMDKn52Vt2zZjP3 xH8m0xkNdEaIpdahvdyb9mvqWvQW+1tvOLiP2eGa/buPF9XkXJ19ni8I9x/X0L+0VpfftZFt hlzKJnZN+ezNsiuMdU9wca3+8B/v/ed7yz/4YPVcjen/9A/24+Ni63CtqLhYet70zwAYdPqP Pg4Ox7ZNtuRR0i1x8F5wuF9PZ4SYnzy4l5uLi3vtBh4J/YF61sZBzJK5O7dwcXFzbVdU1Gqj Nzym0xlx/iHSR1nj7rCdraDub8lFmeLrtnzEteK9v33wt/9b/iHbER3kt3I8w/bWNxnu27uK HhecuLw3cAkZeJLFL79V1A/e9vZsi8PNxSWhrJiewtmslPa9o/KOjzexHm2+WZIdx8t7lJuL m2u7srJ2O72R+VFTVlK1tjg310fcXFwqZg4t1JovIsM8d6/ZuJKLm+ugjYPTMHu35TntNqeO ca1ayxx6nbikZGYex0cg92j0OiVh0U2sgZqbnmR72fPy7ebi4t6+VUjb50FTJcc5CjajHNjD PJa1XNzSZpFyUiEWypkpL7k+L1LzRUSoxy7ujSs/XPY/f/vg739bybaS+8WkgoPzGPTJbLro XLCb6SGdwRQjQx6+3RPvjVu5DHyTvqmc3vPnvqe9eNkv73USUlJZea/wSXMTnZHtZctzdGJc 7tVc3PtUojSOO5icDA7OZ5tkycBpew2u1esmh163if+44XBT6QPODrtN9HT2cHFzrT1yQLq8 kXqjIPL/Z++845q6/v/f7+fz+7TfftqqqJW6996IgLL33nuvhLA3hA1J2HsTEkKYGRcCCUlI 4IoLENRUa1u7bG1ti+LeW3t/f2SQAFaw+rXjPB7Pf7x53/c5533OvbSve877XWFtvEsS9qDj Tc0IgyQIdlaf//ES6SNgZ+fB6xR8hrYxXr9iYo5Mgo43NSMwjLQzvo2wXL1o4i2xctV8Tb+U M7ROxbHUt3u6msrdO5afW2q8afH8BYvnz7cLioWbZx4Wsbhvt2OPZWLY+rV+1kl9eSIEGr4C MYv0t7qYmVmYx6S+irjPbvR0TzT0bssbRpgnxRef0Ya/KCHlq/w/e983Ke7T+4IxPmvF82vH INVcI5YxXXQWz1+4eP58VTs/Vg1twrg5v9TSaKfcil28WzMqrlBuMXSdycbFbVq0bMG8ue++ P+dDheW9Q98kL5sqEdmLk1L09ixetnq/if9pIf0+DCP0el6Qk9r8hUvmz1+sZd9YWDu13VWr 52v5p31JZ53GpiTsEbvdGJWW9SkLRtpoZ8PNly9csXijfk5WBD0l3Gn+wqVT250FrK9uQaJf i8qLrLYunv/xYqWFYvauVc+MPf6sEYj7AAAAAAAAAAAA4I0DxP2pv16lNp4owtMiEvHaK9Zr 22ZHJHDweA4ez83Bj7RCN/mzbu4Jhz9OKhNkZ4v9cPCZzJTQOF3TUFQEv/6V03ewf8nNJbsZ moXlXO1hXSxML/Gxi8Ikf8fmTdmtSao2sEVbGlVWd91n0bvNjSxsnasKyPI2YwUF9e6b97sT RryMbQ3tUlOLL8FTxH0hjLTisYZuqcFhJ7mT+/OsFx6rqzzTTB3jzHos04v7MPxZckGdq1xq HXbXRXIFB0+QhhHfHJmUZKpq7xv7aXOb+JanvfBYXeWhPHyFk0+I9mrfsCRmpsSYk5fbT2x7 JODL/D9kw8PB3hFGRlE+vvVSnxxMQKKeqtre1XqoohtcNgLDCNz9ZX5uzKpl6mo7vDx8yxPw HDy+IwWPNzOODA4VkF5tBnsuEOsGc/GcuESy3c6PtAJfUFCXfxMqLzW0i/OUtMvJwHNCvYPV d67btccRjUNg/qybZtSxQ31QRhoY/7QOSXCSSaF+qD27t3yoji/MEMvoT3rg86lh8eY20b5+ E8GJwqTZ2oR4enS1cR/19Vwg1rH9vTF7P1mzXQ0TGNmYEpJuZ2m7VcvFwKYgLZ4e5R1paxca mPmTsPcZo/FYcWy0lY3VNoN4u30RQZHUVDwHj+ckp7YFODpp6SYmZgy3TxOl3xP3O7rHCMGW 5j6VMdGyJcHBR2Va2Ya6e5FL2qRaEvvnBtIRfGpznKvuUkMsKqB5whg/SGm6KLdix/Izy/xd Iv3COPgsqU1CNdotYL8mPo94vkti9qAbHsJ4+llZpaFDZK6KnZxQe9bt2bZqrXXsLMR9IYww GodDPPzMdKxdo/or6q8KuE/FPwl67zOpR7ITonaZoGyt62vqL4lTVHW2n60q4eAz2mJDPJbu io6fpqDufVbP9xU5PAIer2sSYLkvPmZiyJyiUlEzU1FoI0StWqymvsPHy68yEc/B46FkPM7U MDIkvL9hysewl8KDkbKkaBffdLngcPBxxR5uYTZmmVnkBwKe1JJ/t7mWn51bZ2Mc7qDm5hSO 0dnt7RnekITnBIeU+llgssj3xcZs1i/1FZ1YQrn+Tl93C29Lb5Tx/pCA9M5MPMfXMwXjU1Ta LhkRsbDRzdXH0joXn9klaTq+CuUaoLmfkE/6SVp74Akf/rWmfCA3LsPYLUhNOyPcym63SWx4 EAmPJ4dgky20mhpIl3gwAsMIxPo1K8hFyykjKky8cjpS8OUOluarFxtY6peUv8KzPxN6bzEZ nxVkc/GRYTuM0fbmBXKLVlBR+SWdo7BzPyXUes4K3W37oyKCSHg8B59BSwyJ0jTKTMKN0ibc /pqXUeLvEuMfzsHjpN7iKwNdA7X2EwrIF15UmOF34HRfLE2OVLFLjggiix2m4jk+jvZb12zV 1oxPa5Aus84T6allLsZJ4ZldOOlA4rGNriYG+z2bGxRSrl+hkEYKksrc/bzXaeXEmXnqmIV4 e1Tg8fREfIK2RV0B/ism+2IjkR2HT9i6YqfG/ihU0mAtaay372Zj7aH88HANLYMNG1BRGV2V jdc4PUhn80hKdJSxfUlmIlMaQAYWn2Wi7+6J6qmmyA2n+ydS/eGkRKKf3kotD7yZRYiZSbBH IAefxcH7BFlgqISy8ZlGRizu26sa29d+5mhsqO+d70sZpw2cr0oy2aid4u4TEoJNfxVx/2h3 gKuLilqITenP0hT8CCS613rkx7yyE1UDd1remLjPu0RtHM1LJkc571/pmuFgEmahH+TkVo3P YuMjYw18iFlpX0ss66hWATgfzwq5FUtBByXaGGH8Er4Rdj6EYQTuvcmgny4g9OAjQrYZBjla FsoZCyuqvmJIl3dH2+cVqXhPZ4d9bieE7fdgGOF1jzUS4XQ8J9hK08ivMadyopM9zG9qKoXR sUTnLZvdvKN1rVEmlnGB4Zx0HCfY0d0jil3RiHC5t5uqe/ABDnt0LLfv8bc0SQ7PYuPwHDwm 2tjYy8SsoUb4fHanWFhf3YJED6iCrwtrOIklUgh1IcHhqjrBfsQfyw8DcR8AAAAAAAAAAAC8 UYC4/yKbmxTogPtWNffYg5TJ6fj/MMKHXcwjTibGFo5FhLpX98Okn0iLc9MzLA32jTd3jA7w aiFCcpodjMDwMz48Xhbmq2URFxjxWRf8jAtfSve1U7eIj0j6Sc5srKCg3n2Ljl/RtSo8wdIh yMuxrR5CevsUxH2x1m/hX5CAf71FCKYX91tJNH9MuIM5C+p++IJdpbeaINhPY+1uV6iyalKV 1Jfn3Ofzr5NLYw3tsd6B3Or6iRG11B8I8fI32qqHKpYX92PXfKJnYldXUn2+B0Zg+DEX/jLT F23tWZ1R8spVfxEYRto7fowxXqAb/AJxv+dya4b3HL30lMTj4qKpQhhh1nZHx+SGRdPLKAj8 O8l8pud8ZlKpm0l4IIZD4T2S7EbnjTc1dPjaGS/UzS/K+BKGET7vBrk029AuzBvFrJELDqtp KDEqzdYoMCjnHI/1CIZ/zc2rtd2wzxzNaWq/xqeyfH1dN6xwQGd9y2M9YpXV+gSG2QV9AfOe wjAC17X4etqt2eTjguY2t18X5zPh8W41Ftf72/nboam5pCmR/B1xn/1zTRnV3jYkMfsrhVrE rE+zMkvc/Qqi47+B+c/kXf1+zn0hjDDrGgOD88JDeuvln6PuC+RSiqdNsEfyYHPbXRhGeLwr pJJofTtsSOQgpU3m4YeivFpbfcNdy2cn7ktWXW5NUGB8EO4y3PscbjmUmEJJxApJHQjch8DV xcZBlbHRn02+i3+tjYjfoJWSOI24L2NmOffxMWs/1jV1IJXV/tQDIzD8iAN/ke7lb+lFxJXN cnn33oEaWPY+iZEJfZR2+fn6rqyU4uud4BEs4tEmPa3fxqDi9Ldpa1tFoj1balvHe2CE0fZN VVZzeftj4cTZlIed8GkfI3uNveYmdqkxoVzxfvPmusHyQgEJQuB+BG456BWUZGOfkU74BpYd YOr+sb6o3lXXSSesh9x4RaFpGj8wDLVtnamVWYpn5IHWxiswfKOt+1RW5AEa7YZ4ibYyvo3Q /2Cnd2ddrbjbT7nwxaKMOkxAdUb6dF+kXi8zy7mPDbWbs8reLbCnTTxA4b0OxkEvcw+PEEY5 Tbq8a8n+QXkR4UJyh3xSph+JJWRPK4xH6rHW9nuz7R4LOpfptXOBdU1FgeQPCh9GSAUNoSH5 CVhZQ9dqsylBftnh2GMdgmcy5bSLfbk4DW/lnJqaOdzereiZdSoLH71ujZ6ZbqQrurOi4mcY fsiGv0hLP0ypu9ADIzD8sAP+3MtAz8CukFB+c+I5ys61tHE2seV09D7rhxGY/V12LsXPKQWb d0HYLcvd9JANf54Wm+HsWZeZfrZ7yojwXttXq7vomsahY1kV4sMHzf3p5SeI5Bk/CxJxf6+V PfVRRlqwhXWYUSgjm8P3V9umGgDFpuYlvJq4LzqXX97s451g4hzujMmSL7fLmND6r1MPfBqV CJcJb7ZMEfdbBWcr6tteuaBu948NKU7zdey0tEO9/NvyK6/Afb/BnSfSSkbrK3+G4Yfd8Bfp qDSnoNYihRLQtxobDsagstwsyogtFxV2Bswk537zgYy4oH3uJ4Vy65MHI7WRLjZhrfLivpjm ti/DtJV3aDoY2mREJsMNHYigH2FUM7MrzzTJjhfkJaruN9y0OxydPNIhPoNIPxEdkm6t7pdE e9r3wv8snI7pc+4PjdWSG4xWLzJM/TSTB8R9AAAAAAAAAAAA8EYB4v6LbF6nuC8QPOxoGsor 6iUQuGIyCFx3o70G9ri0kj/i+Sq1g+O+z3Ltxr06NnnZRRcnG/Q96OLADvrGlvYlOWQEluy+ T1Q1D3J36WZNWErE/cCiaz3sz+NCYi00AtC4S738Z1PFfeeQ2vSJPl+jNp4skg6KQOASikVN TddmOQqxuO9ibYiNkHMVHJDo5BgZmfEjzJdsZIZ5N5ito4RcvswmNbXZz2jTWnty6eSxv1Tc f8JkfZNmp2YWc7SeOvnX1sZTOcFJGeS7fC4Cwwjc/WV+fuq2HTm1FT8oCBNFOPPgiqikH/7I 2niJuM+/ySwvUXfNCkOTJoJMGFLcbz4bOjvsAwuCXbomy8GCu6wWhmOsoKH8JxhGOlm/4lzV 9gZC1TWT9SxW0+EEjO0ue2E35QYM/5qb1xq4C43rvtMLIzBdiIlMMdpdROq+L4QRuK4FE5ks L+67urrt2JRe2X1v8qSU55lgKqLjzk7u7YvFfX7z4dQQ67UGhakxTIL8CiRwCYQKR3SqoxYZ 4sh9FnqZuM+DkfJwVyOHCA8Ud7LDLBo2zHOnHbk453s+/ITRcTbVZo9p7DC5aZKTa0X5Fc67 11rHzb6gbgMdHZ3h4Hu8j/eUjY/fvmfHhm0BkUV3hILfGGlhpqjyxKwp3X6N4n5u6s5tufXV P/HkrxemG2Oq41LOz2oggu5fiHE2yyzTglCtU+aFgkrEau0obKr9WTFV/bcxqBBNVXvXyONw 79MXOxeL+8a7DeISs6YsFRjpgxE2PnafV17k1IXEG28ujV5sVpyf9plC0zR+IMZPda1tZO79 3u7p24VYP+PQxqY+NXGxcmMp/4YF3X1xV18fMxP3U6J91xmzeI0T714+jNRFe9qHNuLLERhG uDBSFuKg7xDliZ6yvDPbEkLdt9tSyvLPz7aEAKf7YllShJZ7bkyE3HQXnmqnXZdzdTrEO95B C4WevB64mQRuqI2zLZqaT7yv4Jl1KisrctOiPT5Rp9pp0zfNhZHSCFd1s8jQ8BHJkZqen+JQ YWbGvsG4C5Iy7M0s7+AobY0MQhZnymok2tglBHmQiRyFTCws6FyW1/aPd0VGpZygv/KsyYv7 NazeIBe0gamLY37Gxo8MHAu/KKwlv6q4j0AihESHY/0tVbWlNXVN0DqBDQl1Z2sPP2ifqjIr ivvyvJK4T0px+nCni3ewkDL1TE/ftRY2aa8aytupKGnKXMfGUdy2agYVfcHokV/eb0Lc/yJY e+5S3SxC/jfsF/nMS9ypj3Z2ZTbKXawu7Ay3sg2rftrX8+LOTEUs7tMOXSTSDySVcbFSotIq bHb8a3/M8eQuIO4DAAAAAAAAAACANwoQ919k89rE/T7hIyb9qxQvvcXrV8xTUlZSUlZSUp6n pPzB++9t0/uD4j4C995i1ududSaWpH0+TdO9N2nVmZs3Ozm71BfLCtZVVBgaeJpq4AomCtzJ i/tIa0m9rbOTlnFzJ3SfGDdZ3HfEVKUWyQS44eBAv61KykpKi+YpzXv3P++/v84bHXZslqMQ i/t7Pnl/7hxpfJSUlNdpYhPSf5wwEzzgNA4kBZh/uHjZRBjnfTz3/f8sNaievbh/g8zoc9+8 xz3uKPWlOqws537dmML1/wNxH0Z6YaQhJVpNfZMsMkpzDV18Wyq7bvMEs08QXJS5xy3NH330 Zb36NcFIzTN9sGlqcLq+yCvM3KXf3E28OGtxHxWmbcWGex5N9kmlmKDLo6f26sXiPp3Ui7JZ 9//mLJw3d5GS3LKRskttU0Ie+75AztXvi/s9MJLubbhu9YcffjTVm7KSkrLSupCEpJEO+AaJ 1uu+Ybd7wvDU4NSVzzrnvgQGHJxc7GTN6uHeq4z02Lx54byVprb+oi7egxR3ExufYnzVlFte o7gvzrlPUozMK4n7XZ3ns3xU/rv8k48++ni6MK5ZreSVXP61Yi74b2NQ+aGOxWUvcS4W96Ni 4rop0xnwYaQuxts+lIIrn/rrbQbM1DfKzow7qlBuhMYPTCxwsumBFetIK/KIBX8RZGuyfvnE 23uOShI+9QSH82AWRVZfjZmJ++KCurzWOwrRkBP32TCS6qG9etVHL1ze68OS0k5MydH/cjgw ggu03bZJzhVn1HIAACAASURBVNUq37CovuaJb3j97vZWq9796KNp21VSXq+TlYb/WcEt61RW Hk5Np5VHeUE1DjHNVBMjf1ujohI+0t+PCEhVugaBjmY1NTKDmgZ7G41335s3/ZCVtukaEhSq F8AICzqX57VdO0ZE+Z0iKC9FQdw/ihRmxnjor9yk5vju5uwI2i+Ulj8k7k+ipoHmb7z2v6ui MM0/1p940+J+Y4rTKj92XcV088K71FibvmrNWqUP5s+bLuBLlZSNMaLmZvnl/SbE/W/itLe4 40+3/07JkLxE3aD65Az584t/QNxnHLtbS2rB2GyZs/CTuQuUxcyZt+C/776zNQSI+wAAAAAA AAAAAOBNA8T9F9m8NnEfahqM8jRYtjk8NetoI2OMwRhjMMaaGWOxrkbmrm9W3GezxwswBkpL F7z/vtJcWcG6efPee++/azY6Y3JlGdsVxH0h/wc8Idd6yxY77JUy1GRx38AjMypZ9r/Ejzic 6xBjjMH4nswg6+zy9nJvrpkq3b4Esbgf4ONCLJLGh8EYgzpvcnly23gbWChPr50r/ONI37RI bSiUUymueza4UP7G4n4/jAi4Nzs7L8oiwyirNrdwM9FNy3yFtDx/I3E/3HX/NjtWY/m3DLll I+VSp3zNZ3im4r6pc2pc1lRvYwzGGAO6weU+6ntD4r7wR3xJZ6h1YQVXFGCxT3fbpiU7PPdq lFRwPvUzDQuPguqnVk7+s4r7BB+VVQ6VhKzPpgvjRSbjGrd3UvnWP7m4/1sf/ITTdQViSkbR whjLD/XbqRvg7cP5k6TlmaG4b+ySGY//neX9+BXK6vbBCI9zFYLkXKVjVTU9bWxJUpG9390+ 2kUrCz9tu4wxiHVL4VUPz1jcF34e5uNhrhsQUYDw+xBSvN8G0/CgoMMThwZqGuz9QrRNmxlt P0/7lmCxJn8ifSPiPq2xNsR+14dLdu1IvFLU95TxWsV9+rFfq1uaLNaoOBaczj3w9sX9vdFR 4T310000kzHG4jwWyv/N+nuI+8TqEk97+zX6ecn8XyoFY0TBGFEwVkrtD9T8t048EPcBAAAA AAAAAADAmwaI+y+yeV3i/vXKchZqn6MPfpTeeUcmNHNhJNPf0trjjYr7V8nMbqcte/XsCyIT 5Cpb4jn40DhzS3cd08627odCGJkk7sPwww5Kb4y74Qqt+iRbi/1Scb8PRthVpaZuKf4evGkK eMKdJmrBU4rizoQXFdRVgISvRbkE+MScZnInlMHu7rE8/30b3RtfIS1PC3QWo7Vc1bO5qvpl mZTfqrg/DT0XcuJTbKwCvBN+gnnPZtdifY2+VZijOanhd806xGl5UC9IyxNst8te0E25Pmtx 3ztAdV9dG/vBZA2xYvZpeRjHM5IwO/aW1dX8zPvdschcvTTnPiMtfJ87LiJ2mpQvcjxmdJxN td5jNn1anspXTMsDP6gs50WaWAbmle7ZYuvqiDJGx+gutQzMLt2zDxsfC08jIv8pxX1Bz6X6 3JD1RrmZqadmXKD19Yj7krQ83nmR8V9N/pU33lwmScujUBF9RuL+dA21cT1cgl0tCXntk8qc vG5ek7gvgBF6CkbNjRCVMCU4r52OryL80HZWYQnV4uBcSQmOcZv45wyYobgP323Lzbex9TGx odf0HnLXszC0q8iulCsJ0z0QHJ1hvR1fzX8yw+8Wb0Tchw79VEs/nFR9MIf3rHkEgSaJ+8ND qam4fVuS4oYfN06I77chEddlr5dTTFfGkOQisbIwpuwgtnOSgn+N1MV2XLvFPucUof9tivvC 27Ruvrm2e2BIV/0MC3G/qrjPhhG8j75FAPHPIO6fzYzFu7unejWfbzz5G10a3kbO6UiDf+sn AHEfAAAAAAAAAAAAvGmAuP8im9cl7o8VFJLct+ihS69wOOIrt+ns4wmYAsPdGzSt3qS4zz5b UJS4caljZKqIzlH8iQmHRkbsW4nKJN/i85Ep4j4Cs3+pKiFp7jXR3rZyg2GMWNyHYQRmnUqI ynawSY7Efz2RCh9G4L47HVC9xq6AgDcm7hcl57jbOAdmXpZWSb3T0nIsER1vorJ8tRVxGnGf QDBf6RRbeoPLkYyIUtUWEJidXHBOXH+Vzb1SnOmjauCPRvMb2uTvHSdRhFhUSWLeeR7rEQy/ RXH/YQfn+8I4ciHxAktBbjifGZ1kZ4xGZY7D/Oeza5H1aRwmyUI/yC9xuENO8OLzblNLG1Ch rYVlZztghMe7QSrGG9ilxCccaeuSXzlnslKL7IwDUARZQd1ZiPu+HnZrNvq6YfgtspTcwgds 6GgsKs0nnFlcP6VQ8+8U1OWN19ezXAzcrH2byiVlYCc6WZjLiA3jNfIfC+VctaV7LNbPSEg6 0QEjsDjfUXFLZHjtRFnUlgHvoGQbu4z0bLlyrOKqvyXkwISemrqfemCEx7tSXxypb5+fgP1U LjjX6ipa3KyNd79SQV0YRhikgWRXnb1WtkqboxJiGdicCtu1y9TNrFfolGRnftkz9ZYZivs+ EY46WTlUqa7K/KwglxyMqcqueyQQL6rXKu7DwnudzEPeLuG2LsUZeV8q6PvdF8gVDEwAo671 suJwXo+4D8MI3HzAE53s41VWSZXTkXmXqEQW2sBZO5RNpkwpqPv74j7vEpU6kBg90E6/oZCP vqXDzincxbqktEMxNRb/dmdDZ2BEkY9PMTapn9wx+8RZk2gkGTpGudtSGqSuWE1DmanVkaHt le1PJNWGZyDuwzACN8Me6CRbB1xWzreSlPTi5c29QSkm+sdza4k/c2fXvZttHSdxAVB92xWF G1mfBnmEOFrEp0kz3jTXUlCoAAer2tzaJ0KuzPIJF75UnFkfn95PbLip4Hmm4j4CM3gBQaE6 a91CcpNXbfUIQPVQFGonjNUWNwfq+1h50+raJ3VSlJlBy0iBGzre/M79yYL7JHFf9GtJRb2r rvO+7E/LD9wT27QdvlBS4K6qFuOJG66V3lie4mph57E/hJ3ShTBOSr0dPFtVlb9NJSiE+H3t 4NsU9+EnPfDFwshoK3tsSOSBhk75wN5ohYbS/AlpJb+wWPLLu07XLsrLsZkiNe6kHslIro4K p1fRn0kK29IHM7Dhe3aUEsniYrw3WqChaD+8zrZlmg5VfwZx/3hCULi9Y0pAt2xSxqrauWiP EI3V/9obBcR9AAAAAAAAAAAA8Kb554j7Dzs7f6gp4hKyuQQCydHSWWeHuWM4l4DjEghwbf35 TpniwP2FVD+cR2BEJmXrrNigY5cblcglELiE7N78oi87XrgT/EVcJ9bTUVa6Bk70tARxZbnW 6ORkPVW7DYsXbdzj6Rk2TGq+LS+1zBBu5/n6GpiQxcSG+azQDAt0rSYQ+ksLPmPyn/TBCIv+ TQ2u2MNG84Mljr6BRHz55620ezD8XADfbqofKsqrcvZw2/XBNlM/Wk7+UHExC+UXprN8m0kA LT11iEId48BIZ/elDB/1BZ/8V3l78IS4DyOMOjYqKNLUIoeQ0SVXcbQjNSxOxzg9PnWwbVYD 4d1gth5Oyk3dvc7cTFJQtzePcLyt4xZf0bK+mOTl5mJuU03IYBMIXAKhOTgsxUjVaPMypUWq oagwuKlZvpDv+eKSEvvdqpr29DTx9MVXoextt+6z8ooXNUuk/IdseCjYy9/KMhkVolBoMQAT abLXyy36sx76fW7HD8QSiq+/++odMSmhPeJKtrzeB611fbkYjz3mQTau9IqK7zmCp/0zHfXT XvhiXdWRfAKXQODGJzXY7pqzzRwfGsElELiEnL7Cqp962Q9hGIHhG2R6r/PmzXpOBdFY+R6W ODvH+jgQi9tmn5YHRhi13SH+Iab6ieEZXTipz5R0WqCjo6ZOfELaUBuMwPCTHvh8Smichych TL6OaFSOs2ucgzurjfuoj/szkcgJ8I0zXmPqnQqVU66wG4WYsEi1tYHRqQJS63VuZUsAGq1h Vl+Q+3ln1z1BXQvGz2H9Lk8d9XB0VFOaZOVAyWGx2o5VOblfiKtiCmGEQR0pKeISCFxCekus m977e1F+7jUEApdA6M0nHG/rvC1eGz2cK5UpMTpmYV5+lViCYiftQqzMqit7Hk6I+7wbjLKi vRpOFg6Z4rrN6QSuq42j7j5vVCBLdo6BWNjo5uptbpVLyGTLHKaktQc4Ouy3LszO+6IbRmD4 QTc8GOQR5uQgH5x6b48wja0q65cuVrNjpGd/3cm8M7upoY/mxDouXbpyvk5NWf6F5loOyviT RcpL19lA1ZWS8xN9MMJuP11aJiQQuIRMWlyY59Itzo52+VgCl0Dg5REONrTd4PLl3X6WFBlm ut/ZxpNLyOISCFxCaLqthY2GISoi735vN9LT8T2xiOTt57FuW2x6OK+x+VIPjPD491rqBDlo 191mwfbujMrKHzjCZzNe3ogARlrySh2cQh0ccmLl5yWxBu0WsH8fLo/0UzeMwILbEPPzwhw+ gUC0NfGz2B8wUXA1f4TcMDYhxfIuNzedKCB0JRMqDXbZ2NqnRsosC061tcvXbkWIBdUo3yCP QPG7nUsgcAkppJCAaKN9+HxxuzAi6L3PpB7JKewlJGQaO/hpqqXLpju/eLSh5Q7c95vEIesz Aj5+0xJXNIacJj8WTKyBIz4iVjHJD4zwWD+WhOq/t3jOu3N2GZtXlv7xff10YZAnykjL3zWC S8BzCQRuVECcqb61iWlGVsNDAQ/pbD9blZHnaW+8Xrc4M/lYO+16L/yYzb1YU8IPs9fTsIzy DB+qI43Dfc9hGKkrILu6+Fha5xFwEwVmU1Jb/R3s9lkV5xV+NePDFpLXbElDle57Wk6BNQoF VKMyLKxTMEFsuW8w5/KLyl207Wy8unApMktWKqHCwdzTyrOhsGxcsrzbPi0pExKSyz18PDZs jc2MbBMb5+YNVDVc7+NNrbd8Dp+VZ71qs7q2+vx9+Zm4KUNgnilMS9fe6e0V1Zii0Ml0c6sQ T5/GsnaxrHy3renT0nxuchLJR2/VVtuyyCixJT+fcJDSfpM3NS/Wi+mgHCKFBqA11u/ViO4K KRgu5Iw3ihBo9AEkEOGJQmxshIOT21rHhvhaSRXcZvaxLGzYVssMdCZdXI41htDoYqW3P6Al sfkXSE7cN9Tbs0onxDSCm1gqrd2aWRkSFLElZKCYf0teu2/oGMqp42LTcgKcDP61I9YruQ1b doRAO08WIcxZi/sd7V9UlnIJqZQoF81FhmmhQdJ5IXCrqdd75NVwGh+FiraxiA2MlKxYAoFL IFDD4hLNd1j5Yb+m0xWN3fyNdFBuUuMov2gTfRszCzy+8Wmf+FXGOVecX260zNgpnJQsdaW7 3WrbisVbtMK9I44RyZfh/t9g+AqFNFJI4MbEEe23LNfxrIxPEjctKCCcoHXdFb8luLzbTTW8 7EDHbaZhzl4d1dXnOf2/9cNXKKSRKP9kq73q1sHswsqf2V0zzi7I+urLnGysi0uAfpBsUmr8 w8LUt2qvXvA/66xL3Iu+KhPeB+I+AAAAAAAAAAAAeGP8c8T98dKyevPNykoLp6m9aeFMKW2V WrZCLs62K6aWg1u4duXmtOLyc5xZN32xjkHRX71+kbSk5JZVdujia2m+XipblVdssXMN+wru mUVSCDGtJWQn812KndyxZ11MTsctPoyUZxWYqskVp92fGJ/+Iww/4cBnQ52tN62QXF+opLxZ 3XLrVk258Vr6YtgUGIEFtzsayjU01LdK7p1omkk9EumurvTJErmmVy5X8kgoPPPiHcQvgPFp bqyr0pIVcq5WrVDySCj6HJpsfKmktM5sk7LSAonldlV//9TxApTV8k2rlbajgycd7Wd/U1KQ vGn56gUStztV18fmsu70TnZ7PjUmRmOtfBi3aGonZ0jT2bcUEx3Mdkp/svIL5TbCCJ31S6zd 5iWrlJWUlJUWa2prVVPEe9VnxL1OmGunr79q2hqPn2zZYNDMIo/DMALDtxqZ/W5qG5Q/mWS2 28qtubxths1NB/0EIcZVafFyhXYNW7ol7coYDPLz3iLf9EoHd48uyfebFrqDveVyJWUlJeVP lJQN/Q+RSw5GhgesVVq2TEnDK/54SxHk52mm9PGGtZszyqrOc8Qb+X0OtqUFL9+xVepz9Sol T2zJlx3SRrkwQkA779gybQHMycYwjMBlhTpG+5QmddKza+pHpl4YISdH7ZUvTayRU5L9zSQz BmUgzFVNaZHc8v5k6ybDNnbDpM2qg2hfL/ngaFhVo8M5HrrKSguVlTRySnK+nd2kdH9VmJu4 c8kK44BBChWBacfxUS6LP1lmKP7nxBAiVNU2TRecZcuU9nknitom7VdlHIwI9VszYaZjZVlb Jf21pajGzkS2vK0DIgVUGKFB56Os1ymvVFZSUlZaoq2nW9fIfTTrbOwkho+7qUIPl2jr6RMn XHWfLchJ3PjJ8vlTx7LSydOHPZGJiDEQHuK7ZpohKyutD8WmjCqsB/hiYX658UZlpfkTz4vG Fmw+d+JLTzfrQk6QkfL6VVMdrtru7hP1DdwrPbfR/WV+TuJG5SmdXB+KTT0+pfzs8xbaF4E6 H/xn3v+uUE9Oxl149SdUnnq6l6vJRNOrnL18J3L9l6RkGOyR9SosKfV4J3yD3MZz3r1yobKy kpKy0jprG/d+uFciizPIwmDnvUoLF084XLxzmxGd13h19n27UEGt1vlk+YLJYbRBRfc1TTa+ QW7lOsl6paSspKS8REnZCD1Klaa34sMICRuyW3Xj1HlZukLN0PcEn3ZvajcYJAHGae+ShYuN 5VwpwL/aSirctXu3soJPW3Rsf/OE2ffYEIzqmqlrbPlKpf2+yWdonbOITHF8ktEOaWHVuQts zdL680QIdPgXqBitsmOT5Lrylrk7CFGMXyjirfrwDyWR+ts2rhT/umCN+oaQk8W99+T1+koc xi+9wjy42GqLspLM/3L99RbkgtFnrYob8zNDrPZvk/VBjP5eN3KaCGHMWtwvxibrqkzzAC5V UjYOOtHUPMn+NDY1QUXBcv3OzT6xCuc2pBBb3Z2N5Ja3q18Aj6Zo09VxDheos2DtSrGrXZt9 wuueEiODdu7ZoLTe3sHzANz3HIYP+bm7bJrmLbFuvZJves33LBiBYaSNdjbMbOkCcXHspQbG xg1U4fN++JCfq/NGJWUlJeVFSspb7Zjk2mszjAzM+uoWJDqNy4lXW6A8TxLnbduscn1qv4iz WbpupfJy02z38l+AuA8AAAAAAAAAAADeGP8ccf9Zb+/dLmjagn6Xurrv9cp2QAvvd3dfZU5b ChK6xZ9cCnJGTQuE91hMWUHUixDzKof/jMu+1gGNMaGr3T1P4P7fZukTEfLvdnddmjSQDmkR 0V7e7a7OqcVpf+uDn3C6r8oqQzIYY1DnFQi6LDfeK2zOAwGMwP3P+wR3OjvHJxe2hZE+waMe 9viUWnnXuPzZ12MUPub3XGMwFePMuMadJkXyMz5fYQY7Oq6zuc/4nCtM6CKj4zpnUpnWvid8 /i1oIuwTwVF0+5Tbc7NTYWFc6uy8JauyqBhnSXCEfU97ui9Ju325s/OuYBrPL+J5H/ygm3V5 ujU2xmBcglj3+iQ5YZ4LhA+75UvpTrtiXwHhY17PtRe3K+MRh30NkjdjXmWzpZ8xhPe7u6/I RsFiPxTwH/b0XGcyxpiMcTb3sZB/n82+wmBchKBbvb1P+8TiPvqMkHWF2SEL6eTp7ocRHudq x/SP6nRro/c2i6W4GplX2ewHU7+19MOIgHtDoTRx520+b/J3NaHgYU/3+CsEp7PrLqfnAZsl 9TybNO7SFXuzgzHG4jwSCCbmSPJPuSF0TLMkxM/gOJv7WDhpq7hQMilSs8td0k2skuXNks3F VU6PdHl3XZQsb+ZlFuuuoP+3me/clyAQz778vCi66nvC592EphvI5BkUPuzhXJ/+eZFUOZ70 orjDmvREQzf5ckPo63vK41xhQNOEkdlxjS3/Qn5RJ6dpF4Hhm/UtHOuN7/+/pQ6YCLh9mm3m r4TgPrv7youCw+feYnVM6tVzgfBB98TFq13sh7IRCQUPOdMs7/v9k5f3THjaK7jLmmZernLk D81IUOyV7L3BeSSQvsoky7tjunlhjrPYj/unO+ImFDwQj0jelQL9z4SC2x0d47/byadczo0O 5tSxvOCx+l340FefNUgLqxIFV6mDD2kiBDrxFBq63tB/UXr9ErH/duvoU7HUzjzxlHbkMrlP cle9cJx8+DHt+HOF2rmDN5oH71AP36H2yZyPEYWXyQN3aSd/YyqK++1HrlD65cwEY0TB5YZD d9teZee+wjJTCM6UGrkwAsOPudybHYqv7g7oek/vb/1Ts1QJ7iku72tszuS3d1/fUx7nsvQP 7sUO6HqP4DdBz/WOjosM6Gq3ZHk/ZE/6ayVtGmJc5/U+FT+tQuGTnq6xKS+3h+zuiXuh7vuC 3hk/DqyvbkGix+1DNykTcb5EHrjdfOxJ68AYWThGGrjdNPwUiPsAAAAAAAAAAADgjfHPEfcB AMBbZVIKfgDgbwbn24KCtB1z391s2lRacY3/ppsD/GnhXLgwOff9n49XyLkPmArrq1sziTYQ 9wEAAAAAAAAAAMAbA4j7AADgzdILIw0lrVEeDqoa2pv3hPl4ZvqEsGomVcEFAP7isFuPxGKs ly3QDkw8NassLoC/G0Dc/+cAxH0AAAAAAAAAAADwtgHiPgAAeLPwYKQsOc3GwlJdXYpJYba0 gi4A8Pegs+V4alS0qXVjA/US7213BvA2AeL+Pwcg7gMAAAAAAAAAAIC3DRD3AQAAAAAAAF4T QNz/5wDEfQAAAAAAAAAAAPC2AeI+AAAAAAAAwGsCiPv/HIC4DwAAAAAAAAAAAN42QNwHAAAA AAAAeE0Acf+fAxD3AQAAAAAAAAAAwNvm/1Dc7x//sWfsewAAAAAAAIC/K6yvZyT4vl26vrv6 VoIjuHf8rQvZrxHela96xn54KdzLX/f/9vZ7C8R9AAAAAAAAAADg78j/objfc+bt/98sAAAA AAAAAOCtAE4M/DkB4j4AAAAAAAAAAPCXBYj7AAAAAAAAAIA3DxD3/5wAcR8AAAAAAAAAAPjL AsR9AAAAAAAAAMCbB4j7f06AuA8AAAAAAAAAAPxlAeI+AAAAAAAAAODNA8T9PydA3AcAAAAA AAAAAP6yAHEfAPhL0HemrIrhHc/NH3rU/NY7AwAAAIC3BH3wGqm+Dp3BS6P/TH1NPoltvUl5 VFTld4wTz99o54G4/+cEiPsAAAAAAAAAAMBfln+SuN926FJ1EzelgottOFsu+JXadzanjJtc xk1rPV994KGi8W3Zr9gyLrbsEK75u3oRwpjObfuB81WtMFZiOZjfNUZ5QQcoXcfziFxsGRdb LsDWfVl94G77Ww2IPLSjV8jMgdQKHrbm0+KeX8nwD8V13ORyLrbhqwrB7bfevb8fLfzPCilC bBkXW9aLLTteBt96iWRPa41zt/toMRp94Hb92+78n5XnkOh2LW0QX8VNaxAV9SH0E2+9SwDA Xwna4Uv19IHkci6W8k1V39032NbQtWb2SHI5D1t7upR/vfVtD/yvRVvftwWobSt3YGxwwzWv yWdeapiRnvZyNx5t9Nkb7TwQ9/+cAHEfAAAAAAAAAAD4y/JPEveJLT1orX9/8O47/7Mz0SWP kVeasPtf7/znnXcWmlYFEsflLB+3HT2WkR21+yPlBfOV5y5QnjNHZaNOemj/rcYTzyfr+yN3 KyvKPE23zF2gPHeB8tx5BppBbcmHH9BFCFPOjHniGf3oteRgx/1bPp67QHnux2vmbojwqvys avjJq4/oxKP2wZsNwkskCVcoB++2TbT7jH7sXhN8idQn/nW8YeB2y8gz2tFrFHicJLxE6rtC HrjbfuK52L6p40Cax4YP//ff73zibprESKktt1jxznv/eud/dmJd8798s1Nz8jk0erfpyP3W PxKNSYw+aB+60zj4hHHyt7e76l5EdW6spfamuQs+njNP+T//Y2Fffbrk929hdiSh/JZtiQ8b uEN+253/s/IIEn0Z6Wa+c/EHn+xyNipBWkbeepcAgL8SVKYwyXvPwvkf/Uc106/06zfYFu9Y eaLDxwvn/Gepn03W0OtSqP9k/AaJnrQeut06/JD2Wj23wT8UR+pu00pwyT9Z95p8FuKTbaxt twTAtONg5/4/ESDuAwAAAAAAAAAAf1n+SeI+FYKTnFZ+9P6/5xmU+NWMltYWmSx+571/vbPW ozuSJr9V7VhCtK+2ir1u+lgZZ4woGCvIy3cz1Px4Y0xo/63Jm6Ybyz2C0jWCuomCMaJgjNhY 6+WfYeDbUSZC6HJmtCOXyxJs9QOqfIpOEQVjRPZZYqa/umeV9x9RT/qO4lODNixcvGDhYqWF i5UW6uyyrkwWIW0Sg/EKMtFh++JPlMW/bt1kkOzbfDkv1lZ1xzqlhYuVlmut0K/GHbwn3jDO 4I1UxxrO+eDdd7bGOuV8Wk3t8FV75/3/vDPPsNS/9tc3OzUjt6COCmtMa1jZ69OSIFYWLkcd +3Xj4NO3u+peBH3oJvXARaLgZFFTkfocZ6+Xivuj99sOXyf13Wyd+oUJIEEspV3JTAhzdADi PgAwaxijD9v6z9bXxKo51YW8UXH/+CP6gW/qa2L37se6/m3F/YeQ6Itwx9TgAjjvtXpmnnhK O3KZDN9sGnpMf00+aYO3qANXyYcfMt/wF3Eg7v85AeI+AAAAAAAAAADwl+UfJe53DKS6rf3o /X+vdGaEtdysaaR57PrX+//5RCUcTuZOmNUT8R6BEXpB7AIhQjuOQCKkDT6fm11oqb7TpOxy 8YDM8hEkOhaNyfGKZiZ2XZVcHPy5qoIYlVDqSkWaZcLi4M+U9kYTR1xo6SlJ/p/jjyHhqYS4 XHQ2P0P4SsNhMCLQAerGASYJnJgiTmIJJzE+09PBdqOZv2PFjcoBBBI9bIa/zyuiOKjN22WT YZMg87hwXgAAIABJREFUSKecKR+428hqddHbtm672W6f9hTKdw0jTyXSAH+0LsF0zgfvfqhT 4Fv5E4UuiLX55IP3/rXSBQpvffgqPZw5Izcheo6BFxGV/8Vr80lrS01O2hL5OeXo6zsN8Eb4 mdxD0pnr4vNScR8wYwpxWA8XIO4DAK/E8BWoPVPLjRT2RsV9EQINX4baMzV1Utz+tuL+A0h0 Cm0S7o/jZr/9zvxZAOL+nxMg7gMAAAAAAAAAAH9Z/knifht7sACjPvcD5R0YYWI3QqYJIs2U P3hP3QA3lH1kwqyRxkmvhbG06/L3kmmCeOetmpnjeb3SiyfuQv0k10AKJu9Mo3xD3Wx8dq5q xNcTsjL8Gbk0Zk/QCKFTIXl9YwkhKLXBvf76zIcAiRDo+EOofxCLirJyjLFM78H1Ie3ixOJ9 Z8qKs21sTbcaNUa1XRRnbmk98EuctbJxND+agUCi261HRhJiYu1csQ5xPZMGCPWfIhLcl3z4 vyvtW0Oa7rSxj+QHqX30/qKdIf1Y9ivH/HpVU09MLM4FI6YstICZUD8QkjVcM/S4XYRAR36o okL+6GRXZ8PVO6xVjMOkljgXTFloxcmig/LexomdfREYnJvMJrzaJ2u4SuxKzMg9qIMdkVzs 4uSoo631sUaYXUCm1GGpV1yPtBrtHTL7WHICzj0YF1J7rrQfgUQIbfBWaXEROhrngikKxPUS +hGafMb2kXtQR3dEcrHEW1iRS7YoPY+YThzEc185PshLxX368G0yuSE4Plc8hOkL6g6czi5t 9MGUesez84cu4EspIZETnazquzPJZzN7hJBfKhdqnE8ahO1E2o+/qUdPwpHvKylMfwzOVdZ0 TIN/+TdtIxOnK2hHb5QWFaKicN44QQrl80Zqq1d4tgsG54IpCsQLsydNiugpJBovKGmQjBeT 7YKpimv5OSHp1cV9Eg1OScPJBUfS7ium7x++3NTJx4TnuGNw3jhBCvNG+9HrpUUFqCipZ3jC cxPvy2w8zj1E1nSeZ2xrKvdR47GpkTxX0cCYiGRUczC+O7euCV13oe7gI0h0qZbZG47JdsVU xbX+kkOBk+VGhCoczuZNcThyB4JYYUlFsqZdMLSMnvGGiThfKigmB0fifNM7E2m36ogkjGRN lvkk8guOPWmZMvbm7iF83sQy88axwosHMrLaMniPqbJ5OXYHglhh2CL51ehb9GkBb5bZ3ocv UTt5QWHZ7hhqXBEjuYLsgslzwdAzei4X0/qT03CyfzbI3VVFbIpMkJ/rsvDq0yWHpvp/BIm+ zMiq8Z8IDj2DyIisORxH/XlSNxo7xN0Qv6BqfdIEBbW1EXWfF/LuTZhxBlKzq+SH7I3vS4Nu Tju0qjqqtJN5Lhh6Jvfr7IauqBicW1RFQM0F4qHHkAiBhi41dvDQoQT3iXdjqUvO6Rr43u8F 7YXBlIn7x0mso9h4nGuw2G1dSNFIxeTaM08g0aX8onpM5MRw/Io/LeRPafrQTw2UFvdQgsQs thFVNERrSZ8Q90fvQX2H41LKPDE4F0y+Vzwtjf+EOoJAoovVdF64ZLWXh1d/VjrNHP0+DyHR l+mZ1dIZzHbBVMe3DyVWHsusPdsgn0Pv4I8NlBa3ELxsSfgmCQpHn0lLAtxvGTibmZztG4ZD Fx/PbPm6tKxCalwXWjxaMeHqVn3nEWx8umtw8J616rv1PQ3lp5sApytOd2PPaQIO5xYss8n3 TqCl8Z82TXmD1bcJklKlZnHd0xTUHbpIgbioELw7hprQdDKv8zA2XvqiSGYnNP2i6PB+y8DZ zCSCb5jY4fQFdSmtnbGpBS5xVHTZKYbgYFyyeI5wnnHEKPqzhsHJnWxiHcnKKZGOpTyi9nNC +2k8DucajHPJOlwuGpqV6Mwbo5B7Qv3wvj44HzGo8qjUM32s+29fEP87AcR9AAAAAAAAAADg L8s/SdyHhJ/WZ7p9MkddP/UobkC8kX/bh0quDpWnyl9y720iozfCx8ej6kbFAenFY7cgaqpD LDu87qKCsQDOwBM2GrdUDdwXb4qn9wxXp7rpEq5PfBgQU0/wiijQS53ddnXG8PXmmmg9nSjr BLh40q+DFxoaa3RWG9jlDYs/V0yI+y1XGtgHknKSDffZ2aWexE3Vowe/JTckb5+7aC9KGM8S b+S3mvPBXt30IfzBWXRPynNIdLuO3hEWEq6vZakiwUrb2l7d3H/VnoKMgbtNIgQaOFVYlGug aaq6e+OCpduXb9JRmTD2tU2adKzhfDmV7KhluXfCxkXdJMkrfzC/X1qN9tgtiFLq5OKpsnvX urVrP1yls2OfhdTYW9O6Mvnw/UYRAomu1bSzAq2Mtq+etxvTH8NEIBHSfvgyIcbdzNxy80aN XfrhngykdVTa9PCNNtbB1HC0jpnddi1LFS3L3Tr2m81TDfeu1fPI8SD/kWX5MnH/6LXqvFgr W0cVLe2Nm/cvXYwOmlpQVwAnxIWrbdVdudTarqTQysVHW8tSRctkp6bhErWowOJTNQNyZy8O fEvIybe3sZILtaGaRaBxZH8K/Wrj4Js86DDwaX5hjoGW5R5p0zv1vfY4FcVUnak5eE/8habt 4CV8tJupxvr1mt4azrkRfh47dK12almq7NZR1QsyzjxTMfxU+i3nQfvgtwVVte4O3lpya8wA VWdp7WRs8YriflVtI9rDUi44VvtsIu3SBgg9T5qmiuwv5eiPZGqNpaG9+rb1603CdWJ4WTkt bjZGmnqmKmrG6taJtuXjrSPPIRHSBn+fW1RlZ6ajqi1bsZZ7jTxMozqx7Vfrj8o/qhcqaxvR fv5ynfTW1LU3MVNd7nckm30HEn1fQqqzVTNZ+/FmneA6W3SSubG+1FJPwyHNPmUogzFOl2bW ph0ZJ7VwkkP8tU3tdojN9tuo7Pa0wrYnQBeIQwgkegKJfkiNiTbZu2mLmrkqqsvbzUHH0FJF y3LnbrMdO90tK04XSmdQTAvvdHpGlp38MrP036vvrrXF1LbhbpV4OCO3W3uGcaGBOia2O7Tk Ym6f6ZZ1sIAzm6+eR8+TGivN9fXXLtq3V9NKz9Vlyz4rlU22Jgkk+5BYM2OD3eoWm1cYmecP EwYeQSKEMXK/qesIJsBb38BYfq51PHJ8Cj8t7kMYE99y7rcNns2vzLY1c1NXlwuOvf56q3jN mKGJPgxfJrX3xIUGq+laSx26qun4WRmt3ODRHNIgV9alvRmDRqnID9kyxjKWlckYp0/oqo/b By+Wk3sDvd0lnRS3m1Rsbm+psn7NSu0Ag/SzFX0PINEtSmdfSmiwmo6sXctdOo6bzdNROUdf pVatRNzPcw0vjY7BGsse2F02WlZp7vVf1Bx/1i4LztGv8iuqXO28tBRn0B13SH4G2/q/q6gi h/q6b9Wx2qVlqaJluUPfZ69dUnyM6xaVGGexuD9yE2K3e9nor/l4+bxFqttss4I7HpOHEUh0 rqiuyFJly/x/fbRovb1J0gF8/2yGM3S1mX0wuRxnYeIqmUEtSxUtK8OgUFVDrLkPVCr9XNHW /11FJSnU132rtqSTKhr2GnoRjsUwjnez8RgCie5QBYMRLnYam5dsNYnR9at2c7Tao22pomW5 bYupmkWKZ/N5yonndBECia5UUWn+Nuaq2torFq5atmHvRrn4aAVSFNaDCCHR4Vh/S1XtCRs1 Yx/TGHYy/Tr5qMJwKqqIAW6WKvuNVHatV1obZD+1oO6Rc8SGclNd3TULDfZ7RtklJhpJn/21 Gl46AS25nDtypWhuUwWD4c62uvqWKru2r9xlNW1BXWJlgaeD3hoVk+X6aWkxEUZmjipalioa Wrs19LZ7wsnMW/IfIBs6BrFYrK217Nm30vUqtfbCmu35SGmj+RZPGu7QgVmJzpxz5aWVZvus 1dUtxezZ56xlmIFPG6LRb/S+dU38bwMQ9wEAAAAAAAAAgL8s/yhx//B3DUS86hqUd83pUhHS 1DWYiTZYqpqJoZz73Qqlj9uOjmTWUg1d+NRDciLp0HWo0M8wpH1ySnoBnJGasn5XXgZ8p0mE QCKE2jGQidbZn34xl6+4Ia6e4Oifuif08KxGQTt8sSBEXTOQiqofn/pr68AvCXZLjSK5UbRn kEzcD2MGF7BiMB4rFhrbEa9WHJnW81ijoMl8rbFD2jF8PwIJPq1P91u+3M+l9kzZq0T7MSQ6 E2qvbeiU49kguzgcF+63a+l++Vz/kOgPpOURnKhNcf94jrVtuaho0sbqGaTloR0aKwpVt0o5 Khb3ZRQRylB+iuI+71htkvNHm1NQDd+RJbMwXhpnobJt9Wb7cn+qbCB3mw9eIU2UOFaAfOhe 68hk0WQ2aXlOZxcWaC1Gh0wV90UIJPq1uKrGYuXqFesW7o06iO1EINEtqkDoq7Fkq10Num4M EiGQ6DkkethSnuUQgNdLHJW791IZsdph7/b1nvysrhuvK4PzTGjqPJDirzlndQyK8p3CoOoy vKy0FqwxW2pUiz/8oEWEQEwo3sddeWUgqv9O/UkEEiGM0e/rmPnai1dphxxJYolvvAeJuF5G Wmv++/6iHa8rLc8XOYXxmovX7Um+Uij8A3Um6zI8wwPW6DnuXaayKehYPvcuJDyYUVC1z0fY PPQYOn6/sqzIPzB4X/I3zcOyRfILuafOZMWyfQHCOLpcZu2uBi9rtLpZaZIIkVTpZDAT/E0X rFTZIPYsQiAR0iz8KcZ0p57ejq2u+U7FF6Q+f8jARuioGq10pNcffkw/iUDHH5FbuiOdNRfs xoW1/ijZ2H7sBsQsMVcz1nSvD2NOlAevq8wPsNi8aL3eRxY0XMdlSIRQof4kP905a2PR1HPy M1iR7qNrH6EVe0x2pTg3y37fuiWb3Zyp92qOIpDoGb1PVJqftEk1J6btJ/kN9bhwe01TP/2Y Qy2jCPPkzIP8EBKdxlhobNlopR7ELj8yxij03LZ2+cdaWMeSC+0HfiwJVVULaAsmj0MnnrQK v8oK1NQOZkY1X5HzcCQK7aqt4W9WcK959DfpFuwfiazK/e/vsko/ToDFwbkGMYvNNPYs2RNq knxi4nY+HxsWvnFNZPjRB5I/KPyRiiRn5U+WrnZpU2xoMkUErKWR3jLHburwE0m7x8fJnTS7 bUt3ebRK7j12DWIWm6oarVq0ZbtVvA8kObNFGzqWnpmtvy05ZuiRLIztB34qiTLYoYGxyTxa Jn0K6EM3qQfGX/SCohx9LDm7Ixb3HV23rNmxXzPUrlp6pofeHuvtsXxzmJ/gFnH0GSRC6CPf VjZn7VuwTDt8JLV7YjhZYbYaxj66UXDTMfEMPqoqznW1tFltRsoblhzyoDKFWC+VhfPe//cS X2v5tDzsFm+rwP2WBTGDT+lSDZox+m1Va77qR2q2uNO5B14Yxul4RuuC80Os5i7SNMk+kye5 9zYk6nbTUV2x2GqvTNw/fr+iEO9kabPajJQ/8lRyEuXg51Ul2K0LdxtihzL5j2VHFspT3M00 ty7Y6b0xAG4ffQaJEGJNsaet9XKtEvyxJ3Inq145Lc9PdVC53tz/VUUfTeyY+lcDgYbHobb0 /dop7lPF/Yl2zXevWbLJMsyhRnw86FxqlK++joNKzOfTl8xtqQ8NjZpW3IdECMTriY/xWLJ4 98q5vn7N56pECHTwTEVRwsYPNxtlnCL0IZAIgU4+g0bvxHvrq5qGmqeJpPceCvcPUlm0ctWO 7aq4x+UH/nhanq6O7zIC1d7bgonHDkNvXRP/2wDEfQAAAAAAAAAA4C/LP0rcP/GEcex2g/B6 8/BjmghhjD5qP3yZBN9qOfbkdyuUHkuIjjbSjnRtfNA8Ildobug6VOin6lLqmv+lgv104n56 wL4N6KNZLIW0PK8m7rcO/JJot9QosieKNs3/gdMOXywInpD+JeK+kfGarWofLtw2bwcOK7jd OH2CkWeM4/eofVeaBh+1n0Cg448Zg9dJwutNx16tXp9Y3Hey9a8O7ZJdfNR65HqDcJx04G77 iecTmRBeWdw/fqWR3WW/Rd0uazBr0l7O1y7up7p/ZEDCtv4qXirME89oR6809F8kH7wzUVyB UuJhraUkqW88mTVOjeGNl6d04zWK+0UWG5ascIGS6VfbRhFI9JwxPN5MStLxIKILv4JEiFj7 9nbO8cUKC48+kp96+rG79R1fhlgGRdM+f9kpltcJY/SHWnqZ+jx330nfkOoy7HWt1+jiww7c bT7xG1OEQKP3K2s6/cxMnZpuifd9N3X2Z0VaaiZ8g+9+1CaZqeeQ6EHzgdFolIuBzusS9580 tHfHue9fgxrJZs8yV4ziiGwNdJZphLvXj9cefEQ7/hw6/rB96A7l0EPmyd8gDi0gptwqoo9y 9IlcNcunjOPXG4UHAgKro0pHamWuuhq8PLC6bm1Fsqrdo/fbDl+pF46TDz+SyXbNwnMxpkqr 9GJcckRNQ7LER0/bj94oKmf429h5tNytOYpAwoNpqZm79xMSe66QR55K3oQnn0Ojd6hNla6e 6UaB7HLp1ua6ynwPC70Fe7Pj+Tcoo88gEcIYHScyO603ugdRFVZORbqPhV+mefY52RXa0K0m +GJ937Wmkef0EwgkulhaQ/PUD0P1jNfK2hUhkAhpP3K1pIAYlVSFZklzjs0Isbgf4hHflnL4 AX34CrMlTUs7yjaxv2T4KfPwr7RsJ+2QzmDyOHToy9r6gq1mdenNFxS/tz1qPfwFvozu6lFf MPxYmmjoRyKrbv/7dt41n5eIO3PyGTR6hwqP1/ffaDz6eOJ2Ph8bn7RFvQg3KE2cdfwR/ejV esEY6eC0H/YmoLG7YqPiNmtV5g49krTLG6omhG7w5qYzLkvuPfkMGr3T2FTuaGi2XWtC3C/O LQ3CJHo23Go6/pssjOKCqw1FSUGEHlSL5GIVIcxMc/OLXlB7I0fSxAK9WNzfpqPuXBXafoM6 LP3EMnK/lcHDRfnOs4UIrKuQCKltZIY47VFP+D6bI3sGJTOYiY1w8QxyqBF/GDgSHlns6EnF D9xtOyn5asIYfdjGO1WfbLN2T6SCuD96j4CNtLJy0Ej7tm1UspipTF4iyui/mtVptIu02SXI Gisub/HUCwno+bVy6LH03ueQ6EHTgQ5fvxw7mbjPbvXxTjHyasIP3G2XdhI68YR+8By5OkHL CO+dd7JO6rY8xV1L036Hewvh8EPxLnjG8DfZOTW2WjFRxx5TJlp/ZXH/aYvwDM5z854AKIJ6 dRqDGYn7u3frh1riP2+SzODTNhYjEktQ8RBML9+/VNzHeKxZbmFRNl526AldhEAnHrdwP83w 2GqadipZ/Fd++DLEKNRzqQjKF1EHZY/Gw9bDhxLifFWWbFfNei3ifl/fNSqnXn1zYHhEb9Nb 18T/NgBxHwAAAAAAAAAA+MvyjxL3Z80jSHQsOjjKzi3Hu+BMxRHFvNtD16FCPxWnIpe8zxXu mk7cTwvYty5gILPzloLlq4n7Cmn0J0M7fKk4THN/ACWw7qLMeOtOaw2vsiBcbYSfzy59jFvZ F0WvkmlnVjyHRLdraVRUIHr/Xus9OhK0/evQ9ZcmG89Y3G9gjWDR1vv1ZQ7NdqlrLv1os37S 0cl1iV+vuD90vRmC0b6uesaypp326GT9f/beOy6qK///3/19dje73xQTYwxoEntXrIgFREUp AtJ77733MvQuvfc+lAsCQ++9ytiVofdeLghYAOH+/ph2Z8QEjFlj9jwfr3+YOXPOeZ97Zkxe 99z3Wzu5OxTdZ3m7b0K5uQ9uXdkk9YaUv1ua+COa+1FCp26Lxg8EUlLrNMFQqss1mQg1z2cQ HoGa56BcPy4W9oMHLp24Qr0oRJ2+wLV3+0+sZlXW7yZk/2iaDkm+qyrIz8JOGffGSebzW//B LxbyiCb8MDspZTs2w7pIVILvkOhCbX4OkejZwBoEwk8HhMfJX+O4FTTrT7+ZF1xtDUUFP9Tc x1U42RijV+bUWZZDBw/skKt2zn6x6d5QEUkqWbLqlQfWIGnvnkaPcRPmvbl9z+Wz9NeF9+wV 9l2/sF/VSLUuITeu7Q/0DVaSkDhGbSbLpRZtmk9TkCChuMuI62sWlTTdBPqiC1HJ+RYKN695 LfiWIRCUamlhfVyhMrxhmf42Xm2ToYaLsHQwhnwXISzQQ11F5bxJd0TjW3LjmejcUrHD4upx j31Rn03Mf2BubsHDyUGNhcdWFFMbSr2gz1w8bS9+t3vf5Vsn39mNTMdPHWWVY3MaIOYs2piI 5r6BIibbGY9AjVMQ1uHKVWtxTG0wHoFqRiB3ySvadzWjxqHChgAb8S2M5w6f5XxnwW8ePcm+ 76isfNqr8AZity+TK594mBtz84qhWwo4PXEtoJ1Aw3hkXIahgvQJ9tunSc0kWAUctKDXUQ10 U31oi3HgRY/LwrL/2PWfLvk61ZHM/aiETBPpS6csRu4Ur9B8trbBQEmNk5ti7g9jjDSvH9/3 01n+M2z0y3j2xIHdV8247NtIFyXvvkdU4ft+oJwypyOJGWCI5v4F9dtmJZ71tDOvfx4c63WU yd0yeSAOP+UTkCB9VVI253XYOxmr4sJ89fSNL9gOJDevQlhvESVnDp3yBHR2ezwC1Y1B0cbM ly1EaQvqxiXHaSkoHb3kbduwFI9HIHyXh7fHLaabFx27/cre0A30GyqvtbF2vXDZ1a5xOZ7+ 3cmQu91+0AhpVtFOElq+vLYP6SfZMg9VF0rdMFJwLPEkv+hvLSWgckfYawTVeNDTO06MVV+v cQn1GMqGzf2SxyFeNizXBCjX7syF60d/+fpn4YT1bglv0NyXEjaINy16SX09P9fUzuvM++z7 3zT3LWxOcoZ4l68kkauzJBe3e6oe57Z9QHx2ClveHWR545x8sl4k7eOM+Flvf18x1hPMH3Zy /0V8aq3ObYGLbPwXLhDFffrCma1f8SjrFsR9ck/8LyNg7gMBAQEBAQEBAQF9tgLm/vvUOJWY k69lYMAn4aLg0uxV8U6DXzH3HRwOskf6VJCSUP+KuS+t5cpq/mBTE0uuHLGXPcKula4VT+/Z Ed91kD3CrpVGfJdo7p/hdZX264mtHoqPiZaRlLgi7Kfk/2w9R+Cjq/dOaIq6KkaELF5pYx5l T0U/QmIjyrHamLkfmVZpbGh8+Ya4kJIVuUOz29Jyx7Yfv2n9B5v7eCStYT4yMkLD2Jk0tLK1 iLA6t5K7cgDe+3fdKfmI5n6S6Dk1nUrUu3TmfhMMpThfY+E7eVmeG3VR0NII6fLZVD7rTWgm MDZJXVXj4g1NISUb8oj6fBJCv3whKPGOuS9nFMjj0oPugdbcH/YOCBE6xSEUSfyTRl6OH1pQ F1dla2TJe1vhkipGiLwmt4Wl2M4f+0m+5nea+7JGQbdce9Z/NxRzm1/wp/OK614UEVVvLbpt VvzQ2z8c1cDwtrw+j0KQXtJrSoZuornPYVxhCtEPF5uaj1G/edFp4U4JAmHjLS2tmQyfJTa+ 6+h1WOl5SEt7m5Pz/4QFeujqGd30RX811jf3ITwSgS22tEJFIWV4W9JW0LzAg1R9976jqxXz N+fOy1vyrRe1pFmiTuzE+vlD1teGzf3cGn8zwS/2C10RMV5vtV2kDBOs85aoacSbF6HiShMr bylSAysRVXUucWtRy3eq4Fb1RUfHSWjYk7syFVLS4hB1UAvq9yclhHkD4Z/Z2RsLCGuz86MX R+oSu9DuS77OZHM/OCJJ7dYhFoeFd76PHZa6hkK3KeZ+h6Wu2vVTF5lEMEIq620e8wzj2IEN ryEC4cnmPru1pEN9MP27vaHZMRcP2Jgm9kbhB7184sUu6+o2vFknr11StLmF7WmT58lNq1Cw 1S05ezbjhncGmoCw9tSCuhRVd7jYu3Kc5boR1BtYtQQV55uZmxy9YGeJexO32W90Qb6ZifXx y36u69V8plGwlYRh2G2PvnfeegXhH6hx6aENen9rKSmzRIVYdLPfYe4X3fdychfklmBRsaV8 FwRldDhOb98nnvg7zP13xv2d5r6d11mpAvS7dOY+8c8zyml6cfRzDgqLU+E7cd5p8+b+XFxM oa6qxrXLqjKilrKyGFlZjKysmaCs0C/bBFWBuQ/MfSAgICAgICAgICAgYO6/R41T0WlFFnq6 l65pSPs8XsfZxyNQ4ywUa8HG7yiGaUQ9ho9g72ZZ2dmdVGyMqSY9lp6Iq3c14jsglG6ZMo6u ORlzx0bROEDIb3RTc0utnQzGCLEKe0p7Pouhe7cBjkstEr94mNu63DIPgd495t+8COVCMlzy 3GpRBoWL//2FDY4IlhXn38Ue4V35Mpny+obM/SknO0c+TlEWs6ZY6vP+cFxRieQJZiG7j2ju L7rZechL0Zv79GpehHLTpDl52KT8lZN+z0r+F8395hcQLpKfU1/EJM+jfuMz/EiqazY20L9+ U0v4Tj/KRx6IzIlg+0ZMftPm/nRAeJz81XVP7i+62hqKfdDJ/WgPMxF+9Uuqd10pGW/wSGxa obUy227l2j/Q3E/xE5e3YVPORT+psBl1+wS5Cp4+d1iH4J5POtpMNPfZtHMNU+gPO1NO7vv8 +sn9uiZDTRcR2pP7Gzf36ZVTZq2jdeSYmNTdxdBGBMJ3u3sH8BwTkyH9+fu1YXO/9F6Qp/72 M17myYO/YfiuryUI32OjIXzllimP9QP6g940Go/Jxcow7Totn6ufuADhEah5GioK4L0ucEM5 zTQD1bKgwMLM+hjK3I+MzzCWvnjKcpT+5H5dI93JfUcLCzFRA6GIeWzL2uZjWU+kk/saAmal Xu+e3I/zOsrkRnNyH7feyf1wPz19kws2qJP7uhXrndw3Yb5sIUZn7uORyKQsA6mLP99MtM7s Cwr0UFTQOqJx79dTG62v8jJLC6tTp23MSpdjW3615SZP7n9Ecz8uLFhTUuYIb4Rt0wrl8YLk kg4vtRNnlVM/I3MfW94dZHHjnHyyXhT9yX2fDz25n//U0saJ+5yAgmlHScZr8utwclkK22Ey ukIuAAAgAElEQVRlHWDuA3MfCAgICAgICAgICAiY++up5VVSVr6FnsHRA4Y6pXMkq7RlOa1+ NqZ2CUs9SfoKwhco3NQR0UyxblihfDYowE9bW58rAImjpGKo7oyKcDl12lQt5HkI0RRrXYUa 5iw1tOVNI41yNzm95hdQRgD/RQVOlVjzijlqzcnmV9jMUk8d3q3b5UWCSRnM183hE+yuJ6Js w2n7LPnXbKnfp9ZVqGEutnoxsYHGW09rvOfo7sLys45e6Vwk5XWiuS/hr+B8P5nsv6TWz8VX TEZXvCAHWKln5MUvFOvRjKQQ4733BlvXH5iSJnjk7G3Meua+uelh9ebwWlIVxLSm10mVY5El cEIjycRMqRr11bvMY1qql/wmlTjn5oX4ihYjTX1eLrS5/za18WVCxUwCKVc4UWsQ/rW3lRK/ ogOvR//vWKv/ormPX4LwzwwkZISVAzSxL2irlb5Na1mMKx2Pq6HJnQ3hkbTGxcSqicji8chi 6tJ9iLJi5XS8ubQqsJRd1/wquebxnXhvlq9E5TZt7iNxGaUOeryXzXtccimptNcg/HJS9T1j dYkPy7mPUZOTMQ7TuYvKUF83GxKJNZC+uFvpjzT38bWGqja8nK66ZXPx91ap/n7rKtS8EFc+ HVfzkvLVwNbOJNQu0Ib2NjW74o6J+Dc8qfbpJCuQmHP/pKiXYmB3QgPVIE5rXPQPzVQVEpZO XCTl3Le2P33Z1apkPpb647YK4V8nJAZLyWBuKGejc+5vwNxfhfCvEyrmEupep6BjbHkTGJag cPM4q9sL3zIEwiNh8ZnaIicvmHW54JawNLtuBVs3G1cxE1u3gqpA8JvasLmPH4zMjrvxg6i0 T6P7O5PE1s7GlM0kNK2lkuo2v8bWzkTXLtE9Q4BNCZSQsrqucJeyOCn1LxJrZsklZElLkVbV m2gneFQkWNG/E8IjUPUQ5C55WS1NI2KE8lVKrZ+NS8Pq6hgfQZn7xJz7B+QKHDJgLLqkRGKg GG3O/YhQP1V1tTM6dWGVr+knWTsdWzmLyn6+MVFy7ouH6qbOo/6JeZmcXuBkqLDldjo5536a lug5FrMRz6IV9C9Dav2so6WBuLSaECnnfrWuvreIbIJzDSlDPYRHoJal1OKnkda399Pl3Ceq 8kmQj+2hr26JBySKqUjd4FS9HUKu67s5PXZ2xVzbe4vHf9yvimaSUON8fOV0dOV8EjHAnEQ5 Oeub8smudStp6LoXtX1xoeZsNxzpcu5vxtxXl7O5a08plN3yMrFqOrocpmxvd1tHJRUTWexK 6j3iuG9TGhaioAaMzJFTCimfkbkPNUxAaZ7s4oGadx6iCoOvYGtrLcw/MOc+NlfByF2CP6ug eLWU+Erxm/zc3uD0UJYDCtrA3AfmPhAQEBAQEBAQEBAQMPfXUy6kJat3mcNJp2Q2lmK0FT+M 9tA7Z9CEMvjWIPyrBD9HBaNAXs8+ymfV1WyviUe7NJA9aDwC3VvGlnc7ql0TxNSYZiIQHoHq Z6AAw0viHhKu+KTNGhbEWpe+dsI3OPdds1TOQBKJ1k9GtrXKzW0Me47rEpzySFVw1zX3U+sL dFStODn9rPAIdlNDb1z1M5C/AZtCuKIfAf16ZGSosqzoj7dSQ6teUR1Morl/huuyVLRJHunF YHcTPnbWw9etVDKJTmKlnqom+3lDxUxyvCU1DpbK+7du//IfB1jN1zH3TWVFt+w20C57QbyL EJ5UoMm1l4FRVjL8CfHOR3rdZIqb1Jlr5rcwDSF4BGqagyB//ivMP375y67zaHN/zD8yUfqK iHTsbBA1A8xLCJ8ve5X/hkSIVubKJlaGXv9Nc38Nwi8nYUPlBMXPXLdVzUSSqXtvOLoginvP /qva1RZ3aXqOjAhTETj93ba9322TlYp49uHldrNi5QQ1Wbj8bMg5XqD0DAtVri3fMf7r77zC mzf305q7w9K9WXdwCNq1upQR2yxB+OcGUlxMDP/5kenDzH1ODjGT216UNCa9dpb6V/dt3fLD L4yyvzfn/q+a+2+SYqJ1xcQYmSz0ql9SzcFGGIJ8eS4Jcqhizci1EBz1RSUNQtQS0B8f9Q32 FmU+csZizKuI5KklFPcbcZ08eZxhD5+1mA81MUtkeKiGhuY5vYbI2pXUewjU8joyMctIjvOo Tot7HqVi8AKEz5W5KsgpFaGd9iqVfD9mY+b+PITPleEwk7UsckPHWFxhY2h0fK+KaulixD0E wiOpTZ1BSU6Xf9zNptNgnYUOp8fOXI/7pvRl6/b1kgW9Txs391fSqnpirSVOnpC7aV3sTjPJ cltTvZNHpSQSXobWIRAeiYNKMboiJ3RbPfNpyik7avNcFzHmdeqgLI63m72yirZQCIK6UTEb k5srd+q7i5rlJmnLEJ5k7h9jNRdwpFZIDnLW4b6496sfzvyIyrkPtYxHZWAFTvzEYdxok01Z WJz0ldvHth89wUc199MaO1w9HW6eOnNE655XPs1TRI66Qmy3dbltWje3V4nmvojE0b0cN7ic 1O+SazmkppjIy/xyVEehcDa8+S2ER1Ib2wPi71zcpqIa0x6I6iHIWYdDRJ/doJRcyvVNoLeb hLjsIeWypCbyr2V+o7+5yI9bv/zHDoV1zP17y7E5rZrs3505c/z7g+LnZBLdG9YrVvHbWsJm FrmqCXz1vZJ0fCd6klCkmzAX37FbLhp3kdR7CNS86O/pJKekc9m2A3ULfyAsI/zG9rPcFvX2 BdTa8ps098+d57UR9RskvZiTqCjKfZhZ7gqGNJC7rYGggBCLVQeWVEB4xDvAh+/I9m+//MeP t+M+J3O/9S3U/MJU7tp1KQcpf3K8+C4bY3OOw7v3MJ04t/mT+9hcBXm96wfNvYrfksz95Fpr XZFvt2391z+uKwBzH5j7QEBAQEBAQEBAQEDA3KfTCoTvs9OXubTvly1bD++7wn+GWvCQ7TTT 0Z9ky+nz5pd32Nk73aLUjWSWvKEWqZM6GE97KD6teSE+K0lZXpWNVPNQ6CybtrBztWvRh9qF 5R1+QcEK8tLHKHUUz96+zKUvHFjikPs6rgGB8DOhKdkqfDcPM37xw16WvWdlbiqFGecR/dwp b3cvieuX910VPyMUZZE+HPvRV7J+CvJSOH3u0o4jV2nqZN5Qv6YWa5syikXbB/eWoeoOLwtd Hk7uPeTqu8fPy9xU9tePeRxIqmM8FRYTryUvfews/1livCxiVwR0heztL+36cc+Ryxc10o3R 2XWqhwIDIiQ5zh+8wst0hf/sFf4TV6SO8dgauNf6ls4lENu0vIGK7qtLiVy6dOn4Ff6zrAJn z8jwmkYIysheZtr982X567aPfYpeQvhhn2C/W3u+//kU9/FLNPUqr6vE6EX2hdVtcnEaZqEY XzEJOVJF2fMnt/5jx08n2In1US/wqIgFvggippopa4/ytWO7KXz2Cv/ZK+yHjx7Z+sWu3Rd5 iBGxy7orxyNJzQhUVGZmqs9y/DTjt7t2X+LhcXjgnI8k5t13t1S8fOHo9zuZfjkix6dLTjVT NxCETdM00Gc9y38OVYHz/A0pLn3ILGkigiaF/Yiztd61vV/840vGvWJllnfJS/cBqhsI9PJT EBagfq3Y5K9LGkjYqB/+zy97T4jwWBc7lCDJVWPORtLcFw/+tPf49pMKV1WyvOveJOEf2zk4 c55k2f3jNsaTPBd1C23SYQj/ElvX5hHoKnhL+sIFavnZS9KBN7lELhzbse207Gn1Eq9ceOOT jM7M1FRXYWWhlIG9flHEllvaToR919e7WQ+Lx5jEDW4q6qiMOjNV/gtX+c8yHfxp7/Hth6kF ZrkM7pqgs+FXD4bHQbramuiimqQ9aZ5sktYfTk6QglG9dvnskZ9O0pSBZeFV4zIsd8Qtx5MT pCQU9xtxneHT9eFVNEEXtmW6ocmpg3XJeUE+JoykVI+HxGZICtxkvcaD3t4cqvH60QPh9QiE X4bwvbbGxlznj+zes/eH03KnNUrv5MJQOd7dw4H9/IWdX+3YdYqd3TDLNAOB8C8gfLrIOdaj e5gP0dSMFWMXcpIPexzc/JZ8T/Flcm2bR0CQhJAcG00x2OsXRTCidk0uOfOUSf6Ganuj4oJu cXDs277n54PM5+S9VaOmUpIcrpy6tPfgrWvqMWbpI6lukqdYru+6bCZmVxfa/DqtCO/s7CIk JkNTgZZFnF3YTi6k0btihXgDIzYlz0zi6Nd72A6fp1mcs0J2sm71PqhqpR52RvwsO384hi5s y818Q5BNJcM0kVyrtvkVVIQ3Ule6dpOLUtT6OJexqKKGCP+NH747d/iyg076QBgegfBL2Lp+ /4ggKRGaxeFQc+fgkOak5txHIPyr+JIO1ztx4vzXL1+7RTdJSYcKj5yZje/YBFyLi5k8C/Oh razGAjouurp61B8KNgUOaV/N8CchLagrWPHI3cyI6xZNteHjXMaiNkXocZNLOjx8QiRF+Jmp xbSlLnFqyRmI7d9zatch3uuaceb5NCXrU6uHwj1kWA7+tJsNQ1u6drO/PFMJUKmFqSEH7STP sqnx6UQaxj8PqiE9mpBc0uHi7ivAffUcqhkLlyKXYYnd3dnYRgTCz8cV1elLCF88unPnvtM/ X7XgtmlNaV6FCosNDbSYj57asXXPHlY+Ptc290Li6G8h/FxIkp+4sOjJIzdIfZ7juCTuIO7e 7IqbT7u3BuGRuLxKc0vDK8zXyD/IN1n4tDgUwuRv7tp58PxuHg/KPfLwQC9ZGamzV/jPsnKe PXPwu60Hdh5iPXGF/+wV4bNXNBVCu/2qEaimOzw6gPvq1b0/7Pn50Pnziv7qiUjaPSQ80EtG 5Nq+g0e37Lh6hs1ZP2MoHI9EppabqJAvymmm3bv3/nvHefIG1hM0yXXHI+l41Gd3XiN/djIw NkXx1rVju77+4cCV/bf9KZOMgmoNDfS5b5LjvXLtoqg7p4j5bY4TzJvPuZ8/FuedqCIgcPgi pZquFC+nvqyD8dGfjh/YzSmqmOiPRcpKP7Uz/hcQMPeBgICAgICAgICAPlsBc59GbyH8mJdv tKbuOpUJxbQ8FAK6gstf030qMrXC2obSLNIw4uk7RQipPWsQe1Z3ETEucMFNfrhVikegmu6g 2DQFVYwoaehANZcaX2qu8PmonAZLY4yEGvFdd0W7PMcSkh+UkNPk7HZHRN1FxLjQNXfqd01j XTW/hKC7uhae9MtolqYf1bf+R3BVGJcAaksDyCKhl+auQ013UAxtvK6lnjUddjZuCpoYJbdq xzyaDpNLuwL8faU0ycUt9cPlfNqSGulP2QeHJ+ibEjt0ElFNtMkavZNabmWNEdP2VAjsCSl/ DeFfRGXXWxhjxNXQsdiLqPoZxfcH125mWYhqWoCguzoWHutWT5XQ9dFNXIwgdls9GBeXIK3l sG5LWetU80wE24JAFfedvaNkaYviJpd2+ftRwg9Ud6vzo+6NsVCoQEcVI4YqIiqpH2eFex1D nzsbb6IhfmLbjq9PqavHzEd8QLBoFT/0CUCVgdWN1favDapsNNJxllb11vJvvVOJYGtnfDzd lPUwIqoYEa0AWfv64IZlLL7HKzhZjfxBOY8W91ziMWpiedIgRZqawN2YkFJLK4yIpoeIEz6o ZJ260+/XdED0XX19am/KHnW2CZ3+fr6SGnYitmVOGeudon2/4vKfOjtgJNTXuXzKHnVOtDsW ahiPy8hV03KUoDZzFlFNwuDG0QVLg8Ji9Uze2Qw2kHkmkoJ6DIho7kt6NRkGldAUtjWDjGLo K6xia6d9PFyUqb97DiKq/saJgyGkK74C4Uc9vMLVdTAiqhgRTU8RZ3xQyQJU3ekflSJP/koq e9Y75xMvylOMfZACfchB6h71/vRFBYg9h5F6piwOqasNq34sLiNXVdNBnLhDbDIs0hdTC4lV cD2UHYucC16kpkFaZu4ienG6QU+jiE5xOd7RM0KWZpLBGh4N6Ekml7T7+vqKq9vRLbicJ/1Z /ojkIgsr+usioR+gl/wmivb+X0xShrG1G7UZpsI5ocE/Eiuv6iyqmmyXOxGNWhx3z1A1HdRF SapUVUYX1CVfwepJb3cnJdp/ueS88HST/E0lFRNI8WIqXDIfB6fkaVN+cvXiqUtHUfMCVFxp bEmpNkyKyCVz6t2efdArqR2kYF8WWlCmb+Etpeqh7FTiUkZ7Nr92BArVOc1085JquvWmNsO7 al6AiiuMLWgnaZhpkzIQR9syFvfQyR4jRv2pd5E2TrYpWCEX8n2ZWP7UztxBTpPYQ7RyQEdq yypU3urgEU7ZSJrhA+T6yUR1efgnqFKH9tYJeuhThW4wF5FRaWZE+acNI4fJMkueDgsNVjFw FDG/a0q+pxiTCBlZudHtMcreMEkeDa1DoPqRmPQcZXU7cXJXlneRtFbiZ12JQYmoYu3yJ2Pw SCzugaM9RlTt3Q4xIqrBmneaAvBIOn7dz9LO2YI6SQiPhCfmm1tSu1K506zv8KEFdZGyrO5Q 31hZWTtSNV2lECurqriSR9aGfsqyHuZWZdEZwNwH5j4QEBAQEBAQEBDQ/7SAuQ8EBPQ+lWeo iHHt/oXzqE5TXP17SxMD/QlFMfcdSj79ZIA+msrKdZT1uURcdPPJ2XL+mlrClj3212I/wekh 5dMW9YcPB/RHqmHcy8NP+Oo1ztCl4OpNm/tA/x0Bcx8ICAgICAgICAjosxUw94GAgN4jbJA1 /xXWny+bqdAk6Af6k2s5peFFaGqr+lUmQUy+adpYZPlMbN3yZorTAv1ZhK2dji0biywmy9OC V9DgkgbunWcg/gJag/DLSVVTMaVjkcVt3nFRfHu/YFbO0YnbfE1goE+qtMaFxMoJ6qZNwuqq 6p06Z2vUtBKLB+b+n1TA3AcCAgICAgICAgL6bAXMfSAgoPfISYf3PLvoOc2SxGZSWmqgz0FP Xb1tLm7d/s0X//z3N9u+3srIeEbq0uaK0wL9WeSoK8TGxPjdNrL2K/BalXpVU6sc/4X0GsI/ 1RW9eXo343fbGLZ8992//+9v//ry+69O6/HYbrImMNAnVXiwrzzvSeqm3Xr5lICPYdlcYuta GjD3/6wC5j4QEBAQEBAQEBDQZytg7gMBAb1H0XcbXRPw7tnTn3wmQJvRXEzhExcfnIUPztwH Z+6DswxvRFfQBfqMFJ1R7xpKuo7mPjjzkPs++dNJn3pWf4yI5WerHANQ8frgzMPve+I2URMY 6JMruaTdP74YdRGrnLA9lGoNwNz/cwqY+0BAQEBAQEBAQECfrYC5DwQEBAQEBAQE9McLmPt/ TgFzHwgICAgICAgICOizFTD3gYCAgICAgICA/ngBc//PKWDuAwEBAQEBAQEBAX22+i+a+8XP VnMeAgEBAQEBAQEB/S+qZKKjarUK6M+m9rV2ZKNUIkgQEBAQEBAQEBAQENCfRtEIsrDh/57/ XfxtYvrF2OQsEBAQEBAQEBDQ/6DGZ6bGZ8eB/mx68XLjJ31eI8g8EBAQEBAQEBAQENCfRgsI svoHOvoo/jY7OwsDAAAAAAAAAACAPw2Li4v/nf8ZAAAAAAAAAAAAAJ8vwNwHAAAAAAAAAAD+ XABzHwAAAAAAAAAAAPwmwNwHAAAAAAAAAAD+XABzHwAAAAAAAAAAAPwmwNwHAAAAAAAAAAD+ XABzHwAAAAAAAAAAAPwmwNwHAAAAAAAAAAD+XABzHwAAAAAAAAAAAPwmn97c724tS7PgFuHn 5tYLiirIay0LtODm5ufmlnbAptb2fNq5/W/SU4NNspfivi3GbQlVPQCX4HfR2VyUYs4tyMfN rR8aV5TXXORvzs3Nx80t7ZSeUd/7qWcHAAAAAADgT8rnZe7fjzWyVeXnV7ExjKlGkOpYI1UV fn5JAze3/KFPPbX/RV5P9XUlaGrKCfMbBIUUdnzq6XzerL5dbo3Ss1Lm51ezM42rfrtcEaWn rMzPL2Xk6VkItjcAAAAAAIBPz6c39ztqoUjRLd/95+9fXbeyT8mshSxEt/zt33//20G50MCS wU87t8+Kwc4HDXkhKbUjY79z1QbulxSF6GvJcOzgC8ipbvs4s9skPbUpJWUVRY8/Wof9zx7U JoflPhntHvtofW6E9kpsqPCWr7/4+1c3MK7pmZVYE+Etf/vi7387rBQVWg62NwAAAAAAgPX5 vMz9RhcO3sNffHGY55pTMYIUu3AcOPzF3368KKOEnfzUU/uMWFpbG7mXnn/vec/w7+xobmy4 1D/AjI9V0tY4rOXjzG6TLA496ajNgJ4i8KuP0+Ha6mpncWrDg7b2uY/T4QZZXVlqcGDjPPjF v4/yc7oVryzlO7DtOfjF3xhYFdVTp/6rUwEAAAAAAABYj09v7vc152So7/7+y//bI+nvW4Bv zfM1Ovr3L//xH1ZTKLHl007t8+J5U1ak+SXZ0O6+57+/s76mNpw5s2howScy9/HBss5u3vb5 H63DpyV3Q6TYzAp6W/s/Wp8bobchI1Vl1zf//v/2ygQHFeNbsj31j/z9P//3nysW2djW/+pM AAAAAAAAfEZ8XuY+IURY5PSWbcwS0rFdCNIVJ3ucedu/9nPq2lZ/6pl9TiyuruKDhDSDodKP 4MevrSJtgTYOwXafyNyfbMLmOosKpyC98MfpcPXtSoEBv1dMJm7g43S40XFXlp4H8N9m+uaH C7IKCV1vl9uiJQ6d/f6LQ7eMHWr+qzMBAAAAAAAAWJdPb+4PtOCytfZ9/+UXLPppsQ3w84oU H84vvvliv7BnHq4dhmEYnpmGJ4f6ezo7CAQCob29o3tgbHpyGobhyYmxgV4CoZ1AIBA6e/qH RyZhGJ6B4dGh3q4uAorOvv7h8UnUoFPjw8N9nYT2DkLv8Njo0HB/dye5bffA2Ogk/SSnJsaG ewgd7cQmXd29gyNTY4PdHZ3thI6e/v6Rdz7wPiZHxwa6Ce3thM6B4fGR4cHebuosu/uGRsfX G7e9ndKmvb2jZ2CcGD6RGRieGOnv7u6oyY/11jkn6tF0rwbVunNgfBzVmhL+UF8ndeSuvp6+ wfHBnr6R6YkpGIZR5n5p62AvcS3bCYTOvuHx8amNxroOU+NjQ73UgTt6unv6hwe7uwZJk5ye HBsb6OxoJ5S4iZpb25skoS5iR0/PwOgkDM+gVmdquKeDdnXejXd8qKe3i1CVFuMuxKKd3FLc SmndQegdHiMGPD05NTbQ3dHeTr0KMzA8OtjT1UUgENq7OnqGxqdn6NZxfLCnF7XPugcHe3sH B/qGxlCT7G/MhDT2bfnPvy4a301sgp+WJHje+OKrf+0X8ynK79jM0k2Mjg50E9o7CJ0Dg/09 vd0d5FlNDPd3d3e8O8np6amxoe72TtTyEAi9g2MT62zW6cmpsf7udvJStnd1dA+MDHT1Do6M 0F3viZHRAdSe7err7h0Y6euk7hwYnpmemhjq7kYNTCAQugfH3/1a0U+yvauzZ3B8emSgp6uT QOjs7usfg2dm1huXQGjv6ukZmpyemXm3UwAAAAAA/gJ8XuZ+Z7iY2Nnv93BomJUgCIKUmp/n 2LPzjIh9WCe5xdvXr+ZnJseITM7Mv3r9FkGQVQR59WJqcnJsbGxsfGISnl9G3q4hCLL05uXc zBiK8alJ+OUygqyR+1t7u7w8Pzk5MTY2NTe3sLj8ao7c+djkzNyLN+tM8s2LKfIMxsfG4IXl N4vz8MzE2NjE5OT88srbtXU+8y6rK2uv4KnJ8bGJGXh+8fXyAjw2Nk4eeXLqxSsEWUU1X1tb Q41LagbPv379Ft3p26VX83MTPaMjxW488m6R6YWo1hPw/Dxta5rwSQFNjsGvXr2YXlh8/XKJ 2IJs7gfVLi1Q1nJianbh5cqGAl2ftbdry/Pw5AQ55ImxyfmFF9Oz84sLr98S411ZhOGp8WcF oQnmfLdCx1oI1FDGpuZfrbylrs/aGvLmxdzMxBiKCXh+gTbelTcvF6bHRoaHk1U5Mb7R8XhU 66m5uZfLpK5WFufhqYmxycnpefJVWHqzODdNWvW5+dfLdOu48mZxYRp1YWZm4IVFeAx+ufyW skirK8sdIYKCp7bu49KzKkPeLi8VG5+6unsns6RLZNdmlo64cybGxybgGXh2YXaCOKuF169f v5on/jU2ObdAneQagqy8Jm5RVMAzL16us7up4VOCmZubnXkx/2KW7npTpoHaOQvwxIuFV8SF JPL29fw87cCTMy/m1xuYfpKTcwuvX75cnCWu68zC8puV9cYltX39enn13U4BAAAAAABsik9v 7k8/LXvsxvHjlv38zjlZz+Depuw05f3f/T8OraTyGqJdODEIN3nq854/zMDAwLB375Fbpnnd +AEYhptrMi1FGRh+YWBgYGDiMwiOfwTD8CgMp7tLXLvIgIJJ0SC46BFq0PaCAD8FJoZdhxjE QrKSPQN0bzGR23JZZWGb6SdJqMkMEmU48AuxyaXrUjaxnThHnsPMexgO8xkYxD+i/8D7aErK sOBk2LmPgdk0sCTc11GWkzpLbnkXbClt87bqjCBRhv0/U9rs3XeUz6yg9/4ApckEDDfF6vLw HPph23dbvvrnf7Zs3/4DufXOfUeZzQpKUK1J4ef7+8ozUUe+pMCv7ljkxK8a11tHvKFCMfc9 9exlLhA7Y2BgVgoqLd6UJf3OwHnecucYGHYQxz3Md+O2Zqgd91W74tIHgzAM99/LyzY+d2D3 jm1b/vP11998tRV1EQ/zCRgnNsMw1SJ+XvUsUOTwXurq7Nx/nNm8kNgVhSIXUekLDD9s/W7L f/715dbt27aTW+8+wiAehqtvh2EY7r9HyDLiPLB7DwO3okdaKQzD8DAMpzkLX7nAwMCw98IJ Ae/CvhG6NDpFzsLSF6gT5LG1lZHGGMvfyYBhyk2a6cdFeOfrW7/cJ+BRgHsO99RDSYoHvvn3 Dd306vpN3SZpTEg1u8nw036G8xa2OrxS3IcY9l48IeBeNFAZoM3FfYiBYe/FEwLeRbwKO58A ACAASURBVAOj5En29xOy3G7uP7eHMsE9DAzitnkN997tvL/leabhzf27dpN22cWj18zCrdhE 7WLDSzppWjbEp5rdpMZ8WYlTxjRC9ZxiTG8TeWOM9z1vdLt58+xu9FeQB1OQvs7AfX3PM105 9pLa7rvEJOhcMhhvIcjKwsDAxKlokAkPTxDHjUsxvYHucN8lIUGflsGx33OvCQAAAACAPy+f l7m/nGeodu0sk6C1/1MEQZCnAQKCTJevqgTlUezCoSKch8x5RiLMMh64oiEEQWYRJMuR+8J5 RkZGxkOn2FXdnyCjLxEEeVCdZCLCiOLQTXbVuCcI8pLc38tRwhN3VraTuxlvmpj5xhIyjVgZ GXczMjIyMp4XNXOsXGeSFQ6coqQZHGZkVAp4Uh7qpSLNxLjnFDur+5OOsY2lj4H7VjOVOM8f YmSSUb0TVvbIX4mR8RBpliwXuB2zEGQW1XxtdbXCgVOEmRLJDkbG87JeecU0mXeGHuS4GzIz MDJu2/Lv/7flu63bUKGflPW6U0yfp+flSNsjN1ZWpt2kRkcu7lS+m+0g7BOXl/CANDDJ3Df3 fOArTOmMS90nflOW9DsDrzx0VWJlIoW85/RPV9wCrW5puof7FA8jCLK2utIZo6TIcejHbd9u /frf//6WcTsDefA9p39i98zuHJ+h9Lb6FqmwNxJmZkTHK3fHhzbenop4H2FGRkbGrV9+8c2W 777bjmrNaWaZ+JAUb2e0uyIHEyPLJT6XbASZQxAEuV8eayDMyMi4YyfjeZM7+Y9HaKPpLo/1 EaZ2dkFSUsknRmWXWvzzwX7KFXy7vIzTVWA7c1rUPugZsrqy9MT3Ft8JVg6tsIJN3SaZ6V6C FDnOHWQ8KS8pq+mtf45xx0+M5018Cgtz77ron2Mk//mEPMlVBOnMd5WXYkIvD6ekdfI6z8Os vkU6ol3lOUhtd/zEeN7UXEcS447RTOymaTndtQQpXjt7kNTf0cu/KKUHK521C0jHPqK2Gsx3 dZI8gR74gpSt63oDI0hHnoscqe2OnxnPm/oWxSVE6wsxMv70yx6xYEID8UmL6c7X6QrUcRkZ d/y867xpbtHTj/RkBwAAAAAA/8N8enMf7q5vT1Bm2sqhE1NaMQr3NedkaB79bo+CXVYDyTKf noQHWmvjTFSvXztzRto0o7Cqc3xwAobhgV5Cflaw8tUtu7nknL1zHz4dhmF4CobbWsvycrAo XPQN5LUVrONKyK7raOeD+3mBoTa3D7Jw87EI6xjauWCx2IRorLuEMLesqn1aLoEyP0Jtiqe9 srSwnkd0XCIWi8UGu3oYK3Le4GM99AuPpq1Dal3d0+GNBjvwjNCQGBGmeeWUpJwAn7aJhZUf eZK+lmbqEpJatp4l8DDZGx7tJTwswaanUiIJjY4wkuPgM/KvLCTlo5+G4f6ntYWFULCXlY7w 4auaEVHB5NYp6RnZDZ3dQxPk4Sdh+FGOl76GrIKMgQul02AXMz2hc6ynDvD4dVYSc/r0NbVl aDMfOHflkriGpZsfFovFxmGx1rqSGpZu6ajF2QxtOVhHc01ZQxssNoE4sI+tvcyVE8d379fJ KWjth2F4YqCzvT4bSkvx0bgqI6ckiUFdxIyi4vpnAzBMPT4/0jvyoCQDtTpx0eFWctfFjAPi ip5QWnXdKynLwQY6WmpcOSpkF+kTTW6dloEtfdTRPwrDMDwxMNpeVQB5aV+VMfeIzyetVVtL SW4O1s3RVu8mm2N+7zDlJsloX0exq5iarqmlewgWi8ViE7BYdwslTta9bNduOyTDMDWxf2fN 0xilI99c10usrB6DexsyUtWPf7NL0SmvmTrFjdD/rK0hISxQmfWHQ6euK+g5+EV6O9lIXmbn uSSg5eHghw10ttbhZ9XP6GvthWEY7mzOS7PhkjOP8Qsnx5sQg3XXVpJSNvbLzG9H9dxdXRXj pMqtZBoTR2obcidEm4/l8LcHZf388lAXuy4y1NpQVt3aE4tNIu4cZxMN3pNnDu/i8e+pJTec Hh/pv5efn5VGGRiLdTdXlFQx9vOnGfhBU6GXxW1uKZNY/3DSuGEmoleVuc8wXhSQMHQrqKgl wJPTMNyWleiK0dOwoYyLxWJD7jgayNzitc6sfQjqEgMAAADgL8jnZe4j970sbovyKfhmziMI ghBChIWuCvGZpeIpDV6ODrckxhgL7Pwbi6JPYlbb8OhLBEGWEGToWY2nEecVjgsyBon32maR VysIgsAT/Q/rcShi/CJM1a7wu6Z0jo4iCIIgK69ezLZVVERriUsIXmIR0RPTs8PhUnE4XLSV vZbsLVH3xG5kmnTQ+MV0f1WiJr+8rqNnaBIOh8NBSThfPUVpuZvnz3ELSWrHVFS0zb57On59 lhbXhlqqy5w15dUEr4mbGirp+eKSIRwOh8MlhcQ4qvPfFrCGuh+Okpqvra2NP6uuL6VEkoPD eWB0FPVMQmLvU1cHHm57UJqek+OjfoFbw9zRGxV6cROBMPoSNYOJjppEH3VJdjn7qIRUYpv0 xGgfXT7+Mww8JvGkNDxEc1/+9vkTt2SUbXxxOAiHw+ECfR3NdBQ8krqRmfUebvgN5tr7SoO0 rspbRyXEEAdOicvGyNxi3nlMytkBN4AgyNra6nxvS0tVQeIdE1uZSxdNcJFYciR5JbmVhOH5 10uUDtfWkPGnD1Grg8PhAjHa2nqmpnEPKK0Wxnvb63E52VkY/vOKehY20ajW1Y8e98GkruZ7 2lqgABNTdT7zFASBEQRB4PHeB/W4pOxsY352y6BM/CAqmva8AD8bLRXbUHJfUcHuGtKsF3b+ U/TO4z6qI766grS6G/OICKgFZi2Qs/SwCwvZQA+QzbC0sDrYVFXqpMZznZnploCBV052VrCB qKwoO6+yvoEXLjsrCyNxxTTgbnYngpAK+So5Obo5BKHijXJzN9FR1PNK7kFmKev4enKlPd5J StPcLYDUNicb566jxHn0BI+8RHg7dQ7D99pS7AUE9J3jscnEnZMQeUf71vWDX98wjItqpTZ8 OfL8WWMxeuBgN2NdRT09bM8IdeC5laXySF1RHV13x2AcDofDZWfh3HU0DUUuXr5x7bCIWW5e aeeLqUUEmSN0lYZqCRp4kMfF4XDZWXfddYQVzP0jSn7P7SYAAAAAAAB/BnN/tHMIfzfALgZ3 73k7DI92PsBn3LG7k1HysIvmoHRPTQpGW15ARr+oo5+cKmS0q7Y+UeH8GXm3hLqHv1Kd9FFS gJacAL+Bfwc8TDnp29dMyNQ6v/fYFS4L99SGRzAMT43B7fkhGvwaJl5e1ZTPJke5GclpOQUW tA8Txx148ADnbyvGeYLxkIxPXg4xKf3UGNxRmBrs6Wi5HraOlpEV+DbiFJ92P/eRPniKl1sH E1VW20MNsCTZ1lRfR9qg6N7A+HvKvvYPdmb7cO3mN4gJLqULeAM59ycG4WZfaz0tJdPAyALq 0wYD90tyPJVlOI7xBXRRzX1Ih3k3G7+6T1T5wx4YJj4ikGslb2ziaZdHsVN7HpSmxLmuG7Ol pWVQXEETtSYuPthVTUNA0juPcrC9va4J8rOwcXCFHjymLXT7YTn3JwbaG705OfgNLcPK6Rzf DeTcH4fh2mBZHTefeNpha0vu+kixORagzP2hjkfxEluFzShFcadgmFCd5OeP8fSNLqR5vGC0 Y+Bepp9tdC6e0AHDox34e5C3rVdG2ePuzZfTfdLxxEd8zxVJsxioqXO0NbfM6uKWY7cMw2ua OuH2Smy82gmhkN4aAgy311UleWhoG4aVDxEow0yOwIS8JD9TI7tgnzTUnYXnmRluOueZjBJ7 h7qJr/Q/6SkOxVhbOMWVVzxCTTPH3EBNm9MktYN8i2UAX1QQ5Wht7xpeMdL+3ngmYZhQ5SIi I68n61tLeXXgfmKqr4aYjGto2Sjps31Pegp8bFXZjjPclLZLKCR9tr0myM4F4+WWXt+BurXT 96ShIMhUVdkksvD+46FNLyUAAAAAAH9yPjNzf7KlIjULwrV0kv5KTUmEUiraaMrpLg73V8eq HTqsHldVO0x1q6fuuZqqqKmYJLb8SvHd6ccEyJb1+8t2ZYQnaKO7LQgjx81yTkrbpfgxgrxC EGS2rSXRwVRMWK0E6X+BIAiCzDzpKnYTElB1ScE/HV5EEARZeoGMlKXYqQqdY+FWsAshkHub IzytwPo7voeI3PxW4onyNQQpDDGSFjwnomafWjaCvCA+oLA4NP4I648RltVJy6gbeU/Z1zUE 6SzxkNOV11RJoSvHurGc+8NlxTF20so2dimPR8nFaokVdDEiRyVtE2nMfRnRq5wGDmktIwiy jCAIMtRZFBSsrCCcPNo7Q5r0i/HHFcGO3q7rxhwQGFX2lLiwCIJMNj3Gmh3ZrhHzZHCI+MrL 6bcPsSE+rp5JFZUEmog/OOf+YLGbk478NfW0UdKcSWws535/EzbCWZxi7hOZeruSbMDvGENr 7jcFKllqo4vizg4+Krnr7WbvkFY7Nkt9vGBtFZlsKsNmZea3diHI2urbySYsNiEjvYqw+XK6 bxGkIEBHRVLIxr20a+3t8mSSvPhtbk6DyNIuUuVeC++UiHsIsji18ijVydLIN62hFf0Yw+yz RyWh7o4YzcCnw1OvSS8u9C81W/Gd1XRKaWgjLxbSUZAV7e0WDkH3UNNsz2vwkf8ne0BlzxTx a7Q0OzpY4u/n4RCKe4D/tTrOswPlQSFq3Du1y9qGF4gvLc11D5RqaKlYuSU+JH129S3SUXDX W1nw4o1zFy1SSU+xzA42ZqU5WGkFVzycXqB8fVffLncUBHnb2npF5+GnN72UAAAAAAAAKPwJ zP0N8+iuu7sqF7Nicn3f6CgMw/DA84o4f5EzJ7SxuKZudMvu1vKK3FQU/jYKotK8SnZ18CDl FHtfMyFT7/xBXtPQ8roe6mfxoQoubl62eeSuEnUcHZy04mkPqw897CzC8P50QtmLbO5PDsOP Yj315EQ414NPmNM8rQJPnOTT7qd3pLfvlbHPTqdP59NcmRWgeMkso3uQNKPR3tFHZXcz0imR JMWEeUocuKrp55VDV+r2t839qcEOwp0bCvbxAUU9dG8NPampizR0yhkgzbGvqS3LhPmybUzx A5qmOEtXVzeV8Pvkv9tqkt0xkuvGzMnJqWsXXdhA+WxbdrI7RlfNxis1NZkUTWZuScP9AXiK vijABs390fGRhzWZ0F3U6qR6iF9j1zT0yX1A2/TjmvujfYQiF04DS08Hf9QuK2om37/5g3jS 8SxE/IxpXCGeAMPwk+JH/qLfCgZn1hBgGO5tyMixYBMJ66shwKNlAbFW4sdkvGISsKn02Gpr W2oZYdspRnl3VVWCm5qIgXN8YiypDZSRVdLYPTFMlyW/NsLH0UrOyA3VW15h1f129OMUMAxP T8ADrTWFOZnoYW1EbktrCzgWkhsNNcfZeptoaGeRE+8QGe2CC3UETgrJksz9URgu8hIS11Iz dngnksSocA+xy+r+udD999wLAwAAAADgs+UzM/c3xvzwsyqz/ZyyPuFl3TCCIMgSggyXWPJL ajrZZLajWy5O9nc25qHAxgdbi+08ZJz2FO1VIm1BGAV5CbWgfJRrO3UvLc9JWBCLdM8gCIIs Ps6u9pI669ZFGKM9rD6YekdeSEIaZe5PNNYk2Cnxvge9gOCCDgRBSOa+mqA0v5k7HqFldnU1 x1bIOgJqJJUbWFtDJp4/aixHBxNjLa6mqiJMHZgU9EbMfbjYNdrTWj5+iO71tbXVwTznlLw6 8hxXkbZAGwNHQ9cimqYdhY+jtA/b3G8jPQ0wN9VbEa/OKyO4bszKqkYx1QhCcnPn2nsrQjVu 63vEp2BJoRTk5Vc9Gp6nHuYmszFzfw1BJnofNdbQrI6VqarqdfGw+6gsTMgfYO4T8txDnPQN vFBDVzTVtf3KLabfz1sEKQiw9HJxym1HEOTtMlJgoGDgqhNxDyFX7rULzoq4h6yMPZsKvXlN ycnaPyWPnvCwMCtWVt/G7inSb8TriZX2eEc1cwfviFhqs/KWjtFxulxTQ/eepjuxyzvEJkPk ZsX5BfiuF6/of25ejg61NdHs2nA7Lx3BL8RSn/YT8069gbtqcSondJI66gZpP9sWH6Unz0I1 9wnVMW4G7GJmeXlp7wQTY6lma+fu1rDw8RcbAAAAAID/GT4ncx9uL8jz0r3ws6jr/c7Hk9Pw ZHVpoinPjuuWOGIKfhiG4ZnpqdH+jhTzW4Kntm6n8v23X+08yvqOuZ9rfl4sNLeCxgynM/dz bTiNTCwpf1I+3E/Iwpw/YxyYR++x/zZPu58GSG8Xdk6vrKd/q43GoJ8cHWvJqbG7uWv3jm3k SH74YdvWL//5i6jHB5j7w91PE6S2KTmnxzW8pwU1PnLO/WraUejN/U3SmJBmdgN1Xfad4VSz yet8PkAtx0pkA+b+xMRoy/1qjPgvuw5QV2fb9q1f/vsXUbU/2NyH4XEYbozWvMl1ALXJ2PWs wkvpq/5+TDZq7j/PdHIU/OWfX23d9sP29bh0Q84LXRgAfl7x2E/owO6d5Aa/7D16UzOxtbqN vgouIdfbS+Y4KuZzV0QxkZ093ZQiz9OTUwNPunEmUpeP796GGvPbL/8fkxjK3G/NdNI1ltRw aoBHaS79IAzHmbMrmJLMfeKfTEe/2vLduqFs386kHBJRSlsYAAAAAACAz5+/pLmPvBpDHrvJ nhIzDM6ref0WWZ1CXsXoXeDWc7xbiHKgl17OPcwOsL3x3Y9Utv/w/Y9f/t8hleR3zH3HIExI M3oQOnO/qyQiSOks5U/0h7MwWtbadvQe+29DNPeNjDXCiujfojXoV1fWXs5MpemrcJ/Yigrm h2+/3HlB7MPM/eZgFSdjDdN3Bn5njuSc+2G0ndGb+5tkpmclQ4Hj7AFyKD8z7mBWjWqo7nuJ LseKbMjcX11be/liKtVbmesC7eps2Xnx5B9v7iPIED7TWf8sauTTt6+ZZtJX/f2YbNTcX+h/ 0Gxx8NCu7d9+v/3HdTi882fVIMIQpTAAsrqClNnoC1CCYfjxRyZhTFL6U/oquItDT+47X2I5 +jP5i3VgJ6OkU+2jxwvkIs/E2ryPEyOMeY9sQ4257dutvxxDmfsT/Q9SrY+fsM7peEB/7r4x L8BBhWruN+YFKF3955dbfvxx3WAOcWlo0RUGAAAAAAAAsBk+K3N/auxRYZwLz44LVrkF+AG4 OT7VVfVn0TB8x8gk+eTwaF97utbxywKapgE5z6kUx1ipawl+buZ+U1KGqfj+A9IO9S3V5Ege t9RkG5zk1Q/4LM39iZHR/i7UdcmBwjQF95+WDuupb6dpuAFzv7Eq3UTqwEE+x8Ysyuo8an6e ZSByS9/kDzf3Z2B4Yrivq4tADabIS05eWErQNKkFnZbnY7IJc99LX5DFNKfl/pPn69DR2TM4 ir4DMTU+OdRNaGsjN6isK7eT3LNb0pa+Cu7U2NBgTzu1p6rYWGvZS0yCVkUDpPw9fc3PM01u 7jot65yWVIsaM1ZbVdPoQ819aT2TwKT1Inn+/Hl77/DwOCirCwAAAIC/Gn9Nc3/tLbL04q4u i4y+o0vREDLbi2RJXpK9E5zb9gpVm/RBvJmB9K3L+skjVJ7iKyL19h2ygD4rc59YffekiGog VIAKpiVaH2Os+Vma+6sray9nJsZHyaE8GxwINbh8WtYklVjXlsIGzP2ZtysZ9jeYxNWCfGhW JyrY1pj7v2Huryy9fAGPU0d+UhgZosX5yzWvnO4J+s3ycdiEud9idfSaQWx08bORdRgdGZmZ X16hfmnW1pDXc/AUJZihkRGslzKPtDh9FdzVleWlF+PjY+SGna19eSbCzJyaPoWlI6QWSEe0 q4ygiAzmTi1qzNoEnIvsh5r7tgrMuqEjI4R1g5mE4cVN1SYGAAAAAABAw2dl7sPw6LOKWj/h c0w6HjgcNtLYSkqQy5vQPUSx9rr7OtMNr0laB2aWPkc5sTA+293QWORDzP3uRB0HB0f6tDzD DzuL7fh+RqXl2QRPu5/6Sm+/aBBQVEifHaelMitA6ZIpMS3Po1SfYD0ZOf+a5uGJUXKL8X5C nS2zoHHgB5j7Y31txUbHbqi4uUKP39OEzB9k7tPT31ufkKbNsU8lHddIsxa/be4/xOKC9K7K B+DujfRTV6cPrrWRFTA2+4jmfnceLsz6GptjHo25vw5DT9KDjVWUZcxDH9MZ1h+LDaflaY5L dNG6KBxaMzA68iEDjYx1V1WZsl9XC/DM/NW6v6MdD7IDXMQvXXOtqXw6AsPwED631JWXRy8t qbqHpoxCjrmBoSltWh6b9dPyFOkIUtPyTMJwW6waj5GlV0DTh0QCAAAAAMBnyl/T3EcQBEEm ii2MJTVVbWJLuwsS+Rn47UqzH6GDvY91sbc08ME+m0C9ODX0NMP60CHrjE2b+4uPsqu8pM66 d9On5RlK85YXpknLs1GI5r6iupRbHH12HJq0PPP9z6u0z2m5Z2Y8nURb3P13bTyttT/M3O9I MbXVkefxvP/+JsQ5/jHmPj1La2/7n/pIyOp5W6R2ot/4bXP/Re9KpbaUlrt/5tM+mtXJxHpY 835Ec//18EqHmySXbSC9uU/Pm5ln93PcxI/d8Cjrfv7iV5t+IBtOyzPTNYVT4hXzCi/6sDxB awgy3pNqidE35rvzq3V/V16uTD7KMLipbBMeWDNFnMYgVsnWztcpraMPnSynPa8hQAWdlmem qzZn3bQ8hPgoPfkLVHN/5n66t7PEbf1aZOQv+6sGAAAAAMCn5DMz9+HRzr76BB3mMwq6MnwS YoKiBr5NMCoz+LMeQqD0QWHH6Ip6UqHTMbijMC3YUunG9VucH2Luw4+SIt2MVQzvpLTA5BQl Hc/r4vwluU4yHpLx/iBz/7mP9MGTvLd07aMr6qmFX3selkWGOVnq2BW0Do2PwXBdlJ2jioBc Ykf/KPHBhMHOByVpjnoaV3cyK/msZ+77GZ69qJTcVE90VUc7h/BQkAPGK76MWBZ1aqy/Pd9G TVpS2Tw4vR5dcXaw80EJ5O2Iia4kZY3/A8z9R/kRObiCIprbCoOd1bHxyhdOGhYVtNJkq8cH yxpq6sr7UGqo9jwoTYn18nIOLX44OjEGw3BteKqD6hH5pKaBMaKHPNr5oDXV0UHj6klmZd11 zP1UH+HD1xwLy0gnzPuH+sqSneycg7ILm4hJXaZgmJCkLWFk7uRDXpyeGizWXVGSn/cQmyOO Yu6Pdg7czwn0z6l90kMz6YeJfobqkvIOiR3w2DtVBD4GGzX34QF8fZqvvrCkslt64ZMemnKz D/Oyo2MC4orvwTDxBkR7XXYRFJd2D0Ydfx8d6aoq0DpzSy/CL4+4OJMw3F6THJuTV0WzceD2 VpyvHefl2wEttYQxGIZ76yHI+OIpk5Li+6Rhx4d6m5IcvVVYL/CpoMx9eACfkOqrJ6kYBj0Y 6yFdwo7+pnh/DfbTjJSCujAMww9w5k5Gqupm8fST7L+X728XnFJRTV9Rl/C0MSPc0tLG0tI1 8d13AQAAAAD4DPgLm/vIZEuiiYqaMI+8vT7bIVZMFuExzcnfohAjYyON0EKKiT9HeFYZ5awj zfb9Ib3UTZv7yPTjriJXASHNsJIB8uH9VwjypMRVW5qZhVv+Q819IylBZhENR6hyFJknZaR5 +WICXx6sYW4H5d0bnkWQ6a6HyYI/KAVVlHURberltbWRe+khngpX+MUV1jP3W4OEuPWdopPb 5xAEQdbWkKl7lWnhwRFQRisp7Nnnd+PdtW5LGIdUjk7NU1LhLK2tjbSkBYfHk6v+/gHm/nRX awsuCnqKwNRM7kurb4danPkUjf0dcmjqsU42YSEzzmNalbWD8y8RhFi5tzzYyTs4t6ptZA5B kKn2lSQhdsXgkPJuYinetdXVqZa0NA8FUX5x1vXN/StqFp4+FSPkq9DZgosPD0iKLqMkdZl9 dDfMTUJYq3J0aGEZQZDFoSePIEd7jSuHzhi4Ucz9tVVksqUir6KopoOmKO70w2d3Ha8eE/Gv 6+v6KPc+6NmouY8sza4MFvtrq+pbB8fQT7JzsDrN2QWqn5gj3sBYnBp8nO6S0zqBuo+yhiCT bXEGGAMjyfAuyuIMPq6rSM2sGkUWqDmUFlfe3E9UuKGBiY26N4cgyOrym+f+fOrWgS55I5RG Qy052S4yqsI3UOY+sjTb3V+srqXmHZJD6CBdwrfIZHNZiI7cJXRBXWSqPT83UFZYwjWifKKP dpLPy1IyUjLv0lfUXXy78qgw1NfP0dEz6t13AQAAAAAA0PC5mfswPN7fUWx17vaZnT+fkuS3 wj2iSYHSPdiV4sbDqWrg7hhGrLAan+qpqyLFee7w4ZOnbsj4ZuXdH+sbhUe7Hj7IDw7DiBxk 1cK4Yitb27rhiYmxDnxRZqQeh6y8koRrQXYtYWxiCobbarCOzurSCrapcYnEQp6+vq46Iuf5 2A4cVv6wtDwEP+nzNwRYOWTVLaypFVn93MyNzQy94x+Rzn0/ygvwMRLkVPGMjScWoA0N8jRW un6V9cCWvdeVldyzyBV6SbE/qYm6I89yQcjOxTcmNTU1NcYvCiN5g51bzCYlnVQyeBKGH+Z4 6umpaKhZo0vBhgZ5Givzi/CYp1fgu0e7Hj7IDwq1FTlwWcvePaWyta0bhqfGRwg1d/OdReXl 5G/qR90tud81Prmp5DM4y+tqsuJS9uiSqKGBHkaaItJWUP992ocY2rLdrZUkbonpkqvv+tkb yItyiosbJtQOjg3DMPwwN8/b8BqXikNsArEMbHSgh53SdV7W/Tv3cvCqeMZV3CegCr12teTF m7CfuKHp6BWampqamhocFa4hzMLDpRYci7rhUBeloq8qK6ZLWhw/SyVVsYssFy7sPyaLiYYK H/V0j8Fwb+MzSO/sQWEdB78wdDQuunrallq+eY/JvvnHpP9ZW2NiRIgm6z5hPK3sMwAAIABJ REFUA4ew9IbHz1uKH/kIfHtZy8ojtQpPuN+Qcdfo3BXdWI/UZjxhcOhxVbm3oiCfmqlPCN0k deW0FTHxpTBMvM9VE2ZgKXaewzQ1LonSKDr2/2fvvgOiOva+gd/nuc99b0uPlxKTqImJJtHY jcYeFQsiUqQI0jvSe+9NegcBpa10cEVEwIIUERGl7y51ge27HDpIPe8fC9vAENDckOT3+U/O 7JyZOQX5nrMz15wMJMStoh7fm3txn4ogZWGKJ9UUtK6E8lYXGOBuonrOPKyM1EJGEATpqXtY GKC+74KhT9DcbhPjY+yVj8rsW7dhx/F9Kv65RS/aGUwGgiDIi6qCIFtJGV33pKi5Qxh6zU1D QuP0HtEzejzhPoKU3Qo3M5G7rO6Ulpwq0Miz6m4Z2ZWd/INVWnhd5+hf/vJ/f/nLJzIBIXf4 p3wCAAAAfg/+yOE+iuKzHdyl1m/cuEf4XNKdVtYA38bnd66aW6sYmUfPr7l53e+q5aUTh/du /PdacauI+DJiF4JOjQ0O4B4+um4gr6Qrrx/1oKyZhKIT6DAVX1MSae2s9OM+y/y44lYiYwRF B1jEkiTdg/r28SFz642m5+e7GMmoim/7UX7F0/I46cnsOaGsqG4cko/Jnlv1F3Pdx0hCL/pR d+sgiqLoEAX30OOQgp6Ldzh7Adrs27eDHdQUJXdt3Lbv2I9GSfk1pIERzlq047Mzrfme0irK BroO7Ibezo82u3JZVlLb26eA8x0BOuFxUrDeJQnjkMSb2fNjlHX7drC9qoKCcVhEAWFqbLC/ 5eHDBH25S3qKBtEPyltIKDqBokhX3cs013Cjs5/KhURlPcOT+8cW697rEO5GBsl/9aNVfnxa Pne/2GB7VQWH8OK7BL7CA/jSwquaO/fIO8clYfLz8/NTk685qx89LKkalFrRxkBRdJA09cBD XV7X1Cd8rre3sVH2qtqSu3Zs27f5oEnonZqmgVHOZTA7M1VzTVVVWUXVLGhucPJdrDWUzss4 mF/nfo+B9Dwj0e7kHvmQ+OTs/Pz81EgfNx2xs2d3bNgoqWEXlfucQBxG0dlptDnUTlVTRsmJ c5bl5+fnJwTF2hseNUh51Iu8/Rf3J4ZneqtL73voyKpfVnJPfFyLRybHb5uoquuIX4l5WNHS OzVRHyphau18JaaqooUxOz3Vc9vd7Yqhns3VGP5GxlhoH5H0ziDSqSiKoigDV5l84f/OGkV4 xXEK3c7Pj/Ix17ZxirnBfXG/qzLZ1ezwIfmQ/JQcTsm0W3nOhlKGPolPqhkoiqIz05PdWDcz YxM9+2BOoTAnff0zW37cueVvB20i0p4QqANjKIqiA1MT92MN1KxsAv1vsHeLzY+yM7dWOPaj xDmecB9Fe3uaktwljmpaXw9PFGikloGp39VCEv9g0SfGb1z5Zu1nf/nLB7sVFGPxKAAAAABe 7/cX7iO0bqTU/vKPmw9IO3oWLdhK70GqfI3O7P56brnNz4SEZGxzUoNDDVW2CH22cYtMBKEM h+DvhAapcNYFFbvsgSlCursJt3xPf717nZCQkJDQd0e3GmQS5iZ8wdfcDTLfJbROlF3+6z3i ao7YXIudK51zHxd5aa9VQn6Ev6vSSZ6lQfdd9vDl6xH+2Z1Anv0KfXdMUTuBUOwqdnr3OqF9 lxV9Bfrf0tESprP5i2/miq/f8M1ZyzudtQtmk3mS5GzNu2Mhoe+OKRpmIt1UBEEQ/J3gwMuc wTml4nWzCEHI7U3pOpsPsatev/fbc1fvdJJ6BCv+OYUe0oo/CK6GuuW4kmEm0kNbpPyTJGfe xXc3iZuYJfG99k98lp9ntuvLz0U4dW3TSegocTUQ2/WV0P7jSn6ZvGvGIsQuXI73yS93rZsr /vmmHbJRgnP9I0hhopMCd7enHHzSkh6mW0kJfbJWaLd6RMk9AoIQn+FyTE9++fk6IX7fq5tG 3VtqwqOVepKYZnmcsycJ85jkew8aQ9ir4J5S803PrsbmmO784jMRoVMOvunPEARBSG1ImpbU wc0CjTSPKeJtZOUNB27F89Zt3nkxpvMJgVOKhiBP4nRPiH0lUHDT/guWAdV80xD1ttanaX11 YH63n2zcutu68EGMtYP8XqEN+7dKBtzrocyfOU2t9cGaX66bL7t1806NWGKUBnfOfQ7c01t+ JjuFPhXha6RcLJGnkRwV9zHmF4SEPoHldgEAAPxu/bHDfbQzO81e/PuNB5Ry0I6F07b03sX6 XNrNXXHzuIxFIAaX5X1A+Pt1wsfNkm/UoqMUXL33gYNbPxcWFhYW3r1XzDUHRfvR1rt+6pe2 zn9OOiT5USeKoig6iqL119UPHp9bCHadsPAB05xbzoZvMOe+k7+7c9DdumBVYeGv53f49V4x 9Vx0/s1mFEVHZ2fqePYrLCIqKh1Sj4n08VbcIvz1XlH13Hqe0ig6i6IPrptL/8RdFnW3kt9t weQTRfs6XmSrCnPXtWXXHNr4uAtFUXSU3Fzn9eOPW9iDs+eH0265KNqPorXXzU3YVYuICO82 87v9ckHFP6fjwY1AKcHVUEU/WSsd2ljWtUj5vo4XWTyNXLftyGHfhlYa94HC7MxUa4Kq6k9f ceoSlg69eTMyx1Nhl/CmT9ZqhDZ281Q8i6KEO96qClu4ez9heVNgrn8U7Wh/HqAqLLyRXWKv 3FmPnOmpLMdjO3cJbxXTCUxsQ9HZGZQQ76360xZhfl+LHdVJbEDRZT3z+KX62icyVI7tZLfr 6+3HdP3qpuj5jsaSu4SF9+4/55k7PVkTr3L52FfCe+XOeT6a+9TzuATjYwKNPKab1ICi4/MV s9qeZagI79goeGhOWqWn1vG2oKcm081ol0CpdWs/O2aB7ajnvwyfxxkb8ex26+WA4OikZ/6S wqJrhfdYBBY2zL/VP42iJdeunJ8v+4mwsIx1pr8X35z7bCNTr2rilH84yt/Ok9aZ/I1kY06O p9sf2r4TltsFAAAAfoHfYbhP7kAwl8+cVFVyz6xcGAr3sRB6T1cbYX6h05bm5nYihdzb29WB b27B4dtJTDoTYVJ7e7nrgrZ19JBpCIvFpPa04QjsVUXxrfguCpPFXnOUyaD2EgnN8wuO4ght 9c2NuY4rXlB3LtyveNHdwbu8LKGjhz/mFthvM761o5PMpHW3tRFamgkdHYKhOJPF7O3E4eY7 1oLDtRGpLMaCKWLo5G6+dW2bm/GtHV0UhN3dxQYH6WMxKZ24VvawthDwbT1UFmtZc89Qe9o7 CAtWQ+XZ7883EtfWRSTzfVWARadSiAQcz+jgO0ksWndXGwG3cM1YhMViUrjHt5l9MrDogu/Y U8m8B6Wtu4dCplGI7c0tLc2Ezl4alYkgLDqT0tXGs/4sZ2nXLhL111lKl70WcStnT21EEpnK WQW3rbOHQqFTKV0EXEtLc1t3D3sCKRYToXS2t+IEGkkk0Rh8FXdzK57XgiPwD04fgtBJna1t OIGCOEI7sZeO9PEONJNB6cRxr0AcnkCk0kjE7g5CM46Ab++lsfrmzxwmk9HbiWuZL4vHEZpI rOuWi4T7TDq1pwvfzDvoCxrJ7RONTGxvbm6B5XYBAAD8bv3Bw/2amGsWKpvPXS0dRYdmFmyd GhsbZPEsdEpn9g+NTI4O0slUMpnePzIygc5MT04M0ulz64LSaIyBURSdQSfHBvtYnMVCmUMj 4+yFOmdQdGKkj86gcOvsH23IcHjDcD+7cWKoj0zm1EqhMfpG0Sluj2ZmZydG+uh07n7JzKGJ keHBQRaVTKGR+0Ynpmb4ax4f6WfSucVprMGxsQWrjc5MTYz2kWk81ZLJZObQ5KspFEVfNzjo xEg/wqma1j84NjG9nG5PjY8MMRdZEJWz3yUaSaXTBycnp2e5vZ2dnRzp6+MfndHR4dFBFm3h mrHoLCpwfMlkRv8o95sP882c4j0oNBZjcHR2dnSATqORqYy+oZEpFJ2dRSeHB/voPDXNLe1K 7xuZRNFZ9FfAtxYxhUpHBidmp8fYq+DSaIzB0dnZieE+Fp1CprEYg/PR/cTwCEIXbCTC18jp yYnRPjKVItCZhYMzNTE6wLuA8Dx6/9jUBP9lODGM8O6WyhoaGh6ZYB9+Wv/Q2OT8mTOLouPD CO8Zy+wffZS7SLg/Mzs7Mcyi0fnbudgRRFF0enZ2dIBOpcFyuwAAAMAv8LsL90nkjuIb8puk 9ML9breRfqtWtFfhUq7s2aHsllFeQ1m6OD9OuP9s2c8FAPhDo/fgXiZInzpv7hBVIrjaNAAA APBn8ocO93urInRs1LWUojv7UfQ3y+2ehzho6avaJpUPLfeTnHD/1rKfCwDwR0erCPK11BXT wpBQdHLp4gAAAAB4U7+LcJ+JIITy9IgIN1tbWzNzY/kja//53UFZSavr8Xd/rUlQBHQ3P7sf a+viaDvHzNRKS1fNIy2/rm1ZU9MghMrqbE8TI/Gtaw9IKukY2bpdjcooJCDwbjH4U5pbFNfH ae7CsrKy0lBTNfFPL6iCuXQAAAD8qf3hwv0BUtNDbIibm5ubm5uRwpFv9mzdtV8r1C29gdz3 q0yCslBb0bWkUDeuKwamrjGxD1oYy6plrG+2If1aqNa5I2I/HVU0cvNyc4/ENjBIv8r6qwCs cnOL4qYEcC8sMxMTM7fwa8VtS38aAAAAAG/D7yLcZyBI3a2rxsYyYnzUHe2uV/x3WtBeU5Jm JXZBfH7X51UvmiSWEsnL/upAXX5RqAFPH2RUTQMS6xDyrzWZCwCrWU9PW0m8nqSSxPwFIXFR zDb78cvOpT8KAAAA/KH94cJ9OqEsOURdnI+chrjHo1bKst+cX5nnccZ2Gjx7Vw9JLiMsL9lH UXSIMvPQw1hDbr4WqXPn9EIedRMGlv4oAH84MyjaXX7d1VGJ58oyiYy51/pbNwwAAAD4E/ld hPsAAAAAAAD8ifzhwn0AAAAAAADA2wfhPgAAAAAAAKsLhPsAAAAAAACAJUG4DwAAAAAAwOoC 4T4AAAAAAABgSRDuAwAAAAAAsLpAuA8AAAAAAABYEoT7AAAAAAAArC4Q7gMAAAAAAACWBOE+ AAAAAAAAqwuE+wAAAAAAAIAlQbgPAAAAAADA6gLhPgAAAAAAAGBJEO4DAAAAAACwukC4DwAA AAAAAFgShPsAAAAAAACsLhDuAwAAAAAAAJYE4T4AAAAAAACrC4T7AAAAAAAAgCVBuA8AAAAA AMDqAuE+AAAAAAAAYEkQ7gMAAAAAALC6QLgPAAAAAAAAWBKE+wAAAAAAAKwuEO4DAAAAAAAA lgThPgAAAAAAAKsLhPsAAAAAAACAJUG4DwAAAAAAwOoC4T4AAAAAAABgSRDuAwAAAAAAsLpA uA8AAAAAAABYEoT7AAAAAAAArC4Q7gMAAAAAAACWBOE+AAAAAAAAqwuE+wAAAAAAAIAlQbgP AAAAAADA6gLhPgAAAAAAAGBJEO4DAAAAAACwukC4DwAAAAAAAFgShPsAAAAAAACsLhDuAwAA AAAAAJYE4T4AAAAAAACrC4T7AAAAAAAAgCVBuA8AAAAAAMDqAuE+AAAAAAAAYEkQ7gMAAAAA ALC6QLgPAAAAAAAAWBKE+wAAAAAAAKwuEO4DAAAAAAAAlgThPgAAAAAAAKsLhPsAAAAAAACA JUG4DwAAAAAAwOoC4T4AAAAAAABgSRDuAwAAAAAAsLpAuA8AAAAAAABYEoT7AAAAAAAArC4Q 7gMAAAAAAACWBOE+AAAAAAAAqwuE+wAAAAAAAIAlQbgPAAAAAADA6gLhPgAAAAAAAGBJEO4D AAAAAACwukC4DwAAAAAAAFgShPsAAAAAAACsLhDuAwAAAAAAAJYE4T4AAAAAAACrC4T7AAAA AAAAgCVBuA8AAAAAAMDqAuE+AAAAAAAAYEkQ7oM/jT4WQu8ltnd0dpMozN+6MQAAAAAArwfh PgCLmB4fG+pnMfuHJtHp2d+6MQAAAAAAqwCE++BPg0ZEqnwMT5+7bBadXP9bNwYAAAAA4PUg 3AdgEb0FuV56Ej/p+jWg9LHfujEAAAAAAKvAHzrcb6/pSLdRkJY4zSEhc9om4/7z9t+6ZeBX QSW23vO6qCN/+qJ5UFA+TnAzrRMpc1Des/+cZmDsi9+geW/Vi6eFIdaSF8/ZZpe+7HwL9dF7 kJcJ3oaX1c2Dg+/g30KFCIIg7fUPEwNVTp8/y7kCL8hcsgyrJOPIb2kP4FdA7ya8jNfXVz5/ +vTp06cvKagH5pCoXb91q16rNi8/0OA0r0vGGkH3KTT4eg4ASC+h7o7LOVWZ03LWkVH3CL91 c8DyQLg/p/Z6hIOmBC+TsIgCwm/dLPBrweeHhhhLyKhdMUxp7+l7JbiZmI2xld+/Rc6xFqX+ vsP9genJB3FGGhqmkTH3Wt9OlfTKR4nOempGV1I7yP0Tb6PG8elJ3G13HSN5zuV3XkJCyyOt 6hnzbVQPfjW08uvxjsoSEhISEpISEo7Rjxrbf+smvVY/cazEXU/lIvcmf0FGwimvtIn2W7cM gFWhKcfHz0DiopalRUYna3jyt24OWKV+03C/o/x+WoSXrSB7Z3ffrBd1bdQ3q53Q/CA2XPLw MWUTTWOrOXZOVtH3nzV3v532v5m6O2nFxQ8q3kYw+wvRyd1PU92DPPhG2yux5EFdz3+vEb8m OqnrSZKzvczWI3JXtBbm90wKgstPDQmLT3tQ3vFfaM7LilvxoQtOb1sHF1u/7AcNHSsZdFov UpUSE+hua2toaiAtK35CWDwc+3jBY4zl6K4tunfd09bKylZDTVtq9xE1a51rL96kQp6as5N9 tY8dkTI1NZ+/Ah0c3SOz6qgdb3hxg18Tg9SJux0Y6GFnZaWieE5875ea4UTyag0FXzyOtLaX kTimbmVuOX+WuYf4pj+jMVi/ddvA4lpKs9ND5m6H3iml5Y0kBEGoxNbKRMerbra2trYugXHX ilsZrD6k/VFBUogn3w00MCKlpAZBuEe3s45QGO3oYG9ra2sbmJpS0sj+cfujpKQQV+7nIvNL arjP9dsfLtian1t2Nzsgq4bBXN6ZI1jVPBevgPgyZhtpRWPE6EVwt5MySyve+F0EShe+IsHG +/JeMXUnk8S6N6wN/Jf9PsL9URKjARvh5ublJigQ8/ARbuDNah9D0YZi60u6Kppyxk5ckXnY 6t630/4309fe+KIg8yEFHfov/q1NenYbG8M31H6xmVk1f5yotedpXqq9lPyZA9861rZQRgU3 9zfXF2dei8i4/98YdhartzTNzc13wentFngz+zFhhYPeW/3sVoybm4Orq7a+4vEdF5ysY5+9 SSsnBiik+xFh/p5uZiZWKuJyl85tcXpBoL2FRx8TA93dRXaXpBS0ta7MX37OTk6BqY9a8G94 cYNfGdJ4r/CGr5OTub2t1O6PL9iklNb+1k16DSa9KTtF9vA5DQsdy/mzzMXNKbGivgv5rdsG FjdM66y96Rbg4+bm5nY14datFyz2z7srs3Ki3Nzc3Ny9fEIL8G30MXSY2FOTE+7m5sm9e/p7 ++VWIcPcW8j0BIq/kxUf5Obm5uYf7ZfbjAxPoCg6TKytyQnmfi48LflRJ7cNC7fmV43XZYXl 1jb1LO/2JFgVj7h7zfXUlQ4T0lhbXYUt7Vy65FKI5WkZTrLayrJ7PepIyIJn3gCgKPobh/st t276aZzZ8bXI39d+d+TYEbF5ZyTENF2v3Xn5RiE85cG9G5Zin0u4FXe8XNlf17+y2/YqXl5X Y2r/e3ukdrfd87qofVFM7MiuXV9//t7fhL79RmidhJPLzeercoRW6HmEspG51SLh/n9b+e0o e/W9274V/YfId8f2c8/vs2KnNC0DMXnPW5b9iIHShRR6WGpdFBOTVdPW9o212SIVfffNwv32 R8mJjvJiYhJiYjZRHvK6nr5vK9x/iXFy0T6307K4k0R/KxWC/7rSgnhnuS81I1dtuN97M1Bf TfG8fUwDQocw/3fieU6w96XtOzZ89M6GH8QdMm897UIQhNTWcMdZ/NzWD9Z/uXmHrI0NpoHO ZCFNWfGu+nJiYj8dPvC98P9+tO5L4TU7TsraRhIQRt98dfjy+kRj8bPbN3zwr39+fvyMRfLL HoTVhzRlubnqSx3aveWbT94R2nLigP61m/ebEIRG7W15lp8RaaOsIcu5J4sdkL5ioyGlr6a4 WTd9ud/5aMp0dVU/uH3Tho/WbP7h5Mnjc1UeO3NeXM4q9eajDkLv8seIjEdKLaW0Q2Iyni3/ w4vJNrZzD4Jw/3fn9xHuDxC6H/nrim/f9P6nX2/Ze0Cc65yapXP8/Wb6G1Q+xUAHYvR/lLLw vf3gTer51bQWpsXrSzvUouQFEfSvB38nNMRIXPz0cfGDG4X//ckXnwlvPiF/2r1iAEWn/3ut +HUxqjDp9uKLh/v/VSQS7qb72TNHNry7YdP3Ww/ynd96NhHJ5S0kFF32Iwbc7fygK+LiUhLn dcOuW8taRri/Wbg/Tm/H39DRunRBXNzY0cw4Ie7K2wr3BzprSozW79ZPSX+y4nwL/Lbor0aT DDdd9l614f6r+rpC91P/Oe19vwc/9Fs3BvwySFddodMpyR1rPt24Zc9l7+BiMvvnTTk+TtKb v/18zaf7ZJVCq2q6hlGksaXgqra4uKS4+P5vRNd9JvTRZzu/FT3hXEXCc25RU+Po0wgf83O7 Nn/y4Xsb3j3uU4xDBidRpPFewVXVs6fFdn/+r/Wbd26Xd3dIrUPRWRQdIjVV3Y3xcNI6x7kl n5DRUta4km52RFg2KqOCuLzuNBYWeF88tX/jmo82btl7+PhclWfFxQ/LGQeE5LbgV/YgtwMT Gxak4fJgRR9eoCmrPNYcwn3wM37zaXkq7mPcZESUQps7mud/ROlsydBap+GUHPOQxuApyqD0 dLfjeBBaO4i9DITVx1Ooj4VQiJ1tBFzZ9Rvuut/vMr/xpLZmrng7gUhhckuzWExqbzuhFc+p EI/DdXZT6bw75dnv/FYmjUbqasXh8Dgcrr27lyJQfAlMOpXUgSPgcUnGF+3snK4W83Sorauz lyZQvo/FpBAJbQROGwm4ThKV/kYzTtDr0jNc1Hd+ejE6QnrXSU0N39yn3E4waCRiVysOT2jt JLEovURiO2ffuNYuEmku+OhDEDqZ2N5OwBHaO7vITFpPe/v8UOLxhNZu2oI3Zxk0ErGTgOPt cHtnLxVBOIeESaeQOnB4PK61i0Qi9VK4x7u1g7jIKrh9LCalizs47DZXhS0I9+kUvqoWWVCX 72TAt3V09DJYfX0M8nz3VzrsDfduhMh+JhXexk3gSW1ImrbUXkkZh/isBYd7GTorm27Z7JR5 03Cfzy1r9zcN99kjiW/F4/L8tC2UT8tH4mob5q7Ato7uXgbSx3PB9rGY9F7umYPDE3Ct3SQa g3+gaeTuzva5o0Cm0ZlMam/v/JnU3kNb5iXI10jea7+Hxlh2TVwMam+X4OndxXd6I0wag9SB x+N5trL6EEpPR1vr3Pnb0U1jzb03zFd4bnNrN40+t5nbhbaurs7u7g4cDo/DtffQqBQy52xv 76FRGQjCpDF6O/B4PK61q5tMIlPmCi/eSD5Lhfucmhdv5MrMH27ufZFEErhQOPst9DBX1ZVW C8rH4ZrnS3cJlv6Fu+3p7mzlPX6Eju5u/jsFk0bunbtBkcmkXjKR965CXvky3XQyT1XsW1Bn J4nRx3upICyEc6q0trd1U/v6+hjkrq52Ag6Hw7e2dZL75u64LDqDQmzD4/HzXWAxGZQufBsB h8MR2jq7SXzXIJPJ6O3C47m/YXir4qDODc78Vs7ZvsILp7MiM8vh7C7jjIJnnVQGgiBIH4tB 72lLNTtm6hwc8oC/NIve+eJh6Jl3T5o6KZ4/pS0lp55MpTF5B6cLQeLNfvhm8z9Et5254lRC IrP62D14eTsqQGGzRDSlupVdE66xLNJ4h9A3km6hudxH67XRamqH17638eAKwn0EQZDGtGRP 88NiPiV05nyS39lam+K6930Zxzs3n7CHpw9B6OSutna+u0QHkUTle/jJpFJ6OlvrKnC5+meV PK7GFvIUbu3ooSz85cVkUHrauHczfGtrJ5ne3dFNovDUnG1s5x5kHF9NIXIKtnUQSa+/9sGq 8PsI91EURftQFGOxS909uvApz09r4694W+oa54xMoihn3dOZqckxhMqgUXkwBsYmJ2f4q5wY HR1gUjteUIuMxY8ZO8UW1nCK9w2PvpriKTo1PoT00XkrZPYNjAr87cuzX2bfwOir2Wl0cghh 0GlUKpXRxxxc3p/Ks7OzrwaZfQxq5c3oQFVxk2Lqy875ndMYVGRsckqgP+jE6MAAk7eNAwOj bzRryswgceSRscRWVVtjRQMrjW0Xgisn0ZG5gZ6ZnhwbYlDpVCpzYHR4ZGxsgDtANGZ//yhn AKcnxobYG/uGJ0dHhoZ4hpKODA2PCzwv4NbMqY9KRYYnpzg1zg0OnUpj9vcPj8+OIUw6+3jT 6K9ZBXdihG9wmAOjxLIF4f7M1FJVzQqcDIyBsfHJmZkJnu4zBwZHlx3FT09OFJhsNfVM4Evg nyckGCjuOmoZg4yxpgUP9y81M4U2h9o6v2m4z4dQ8OJNw33uSDaV3w4/+/eLvo+ynvIcn/Ep gQt2epzvzKHSkf7h8Sm+IlNTE0MIlUqbPwoz05MTQwwGnUqlUhl9g0PLTqsED/fctT8oeO0v x/T05OgQg8pzf6JRaf0jU9PcvszOouOD/Sw6/9aJ8ZF+1vx5hwyPz103fIU5YzM8f1lxu0Bj MJDRUYROp7NHY2xqdpRzfxocesVTFY3F7B+emB0dYNDpr2skn6XC/dc18tWbPCucmuQcbnYT GX39YyjfhcLZbwP2boTxt1ssU5414+ZL0/rHplZwWU2NTwyxeDtCozOZw5NTM9w7xezszPgg g0Wn0lj9/cPjM/PjzL6rDE+iMytbpnt6kqeq+W4MjL9a8LuNe6r0jYxYrIhVAAAgAElEQVRN TE9PjI72zw0+a3BsbHJ+cCZHBvuYdCqVxmAxhyenZ2YnRvr7mezDzRwYn+apeBZFx0f6Wby/ YbhV8QzOq/nBYQ2OjU1OT02MDs6d7SxkaGy5F870+BA+Wk7PIdgPS+Bcv1Njg7UZPlcNpQxu o7RhntKzs+jkSImnnL62zCkTV+c9H10IanncKXCOlef6KR/+vw/+88kP6jfxNbRJ9uaJkf5b uhuu+GYkv2TXNDk58uSG6blTYkoXr5ZzPkx/kpKos1Xo4w//eipkueE+iqLoYFv/Y/vjh+yj 7jWS5nuDorhc23OGOnYOhZzhmZoYHeznu1wYzL7hcRTlHpCZqZlXg310Gu1plL+nq4JFFt9Z wRpYcJrNoujk2GAf792MNTgyMDgyPMBTc1NWeaz5HveXXb3Uvrn/RdFptP6R6ek/zHN98IZW Y7jfRyNS7lmoydlYBd3lfc3saaqH7SkRHpt/OGfi9xTp5c0VKF1Ihr78sS0i//nww/f+/be/ vfOhkJAQu/iWn7YaZBKIlPmi3d2tWL8zm/du4FS4TkTkol1u2VP+JlaluNmemttqf6v8Kb7g brDqbhGRtSIiIqftPTECxZfQUpoVLivy1eciH73zz3fffe/9NTwd+lHlkl+xQHlyR0uG3rdH v+O0cZPIxahb5W80K3pVop290pEfrfKaWiPMT5xR1Qm+zh3ol3dCDFW+F1m/ecfFqLabvoaG ZzZxGrhNPXx+0l46glQlGJ4+s0lk6/FLutfxxW6nT++eG8q1G7fssSoofiEw8czLOyGGl7/n PYI/nlC+moUgnCiu+VFGmIzIF5+JbFMPjwoNyrA+ydnzOdOohavgktub0nU2H5kfnPWbd8hF d6S4LAj3nyTxViWxyIK6RCIu10fsK3YPvtgnKRlQ3UVmvEww0D+9SURERGT9NyJy0fmVy359 eZFwn8VEKJ3tKRbGZrYK/iXLrZBrlYb7XV3N2d4nN+5aL/Lx+/9+51//+OcHIsLC7JH/5kcp q8BqhMoTTtG6mp94HT+5a/3cwfn0K5G9tlEP6lr56rx7w17+hIiIyIZvReRjC6oIOGzAVeWt 7E+ccSrIrFl2IzubsryOf8HZrYjIBhEReee7T5ddE9cLbICu0lbe0/vgKfXAHATh5mtNJS+D pb9ct5Znay8duekmeeAHERERkS+/3i5tW0yq711YWEREROTTr7fvtS1+NLe5q7Mpy/OnDTvX ixzS1FQyN5cWEVkrInLW+W5WckKq+Qn2R846382qQZCmkheBUl+uWyuyXcs6LuxGqrkU+/Yl IiIickiwkXyWCvcbi+dq5jRy0469tsWlDSt4V5mjIN7m4nGecTykFRQskPY2Fr8IlPri87Ui a95751///ue/PlgjIiI8X1pTsPQvc8fF5uJe3uP37QUbW0wDb5GGoqQAKZHP14ps176WEOaX ZMpp5vYLNgk3G15X9VIq4nmqEhEREfny4EXZkGcUvi8j9CAIxkV8/x4REZHtZ/ab55JpzBex WponvhYREfny+wMKCeRnbQiCIEhnZV2a0ZHPP10vIvKtlK3dzYbu5mcY9fX7N4uIiHx78KJd yDPebzk0ND/zV1//Gecuz66qRmAymDtOVrJ7eLbW5vloKmwRERH5UkREwb2k5vkye8yiU1qr 74XIiOoGFefVIgiCUNvqKt0PS5uFhN2uF3zo2Vn5ItVyz7snbXIfYRKsrNUvbDPKo/A9amWH +/Im508qGSh9JxP6kMZgfx1NINzvrMzIcDi93SAtrxzP+2CeQerszPPwsdB8e+E+i9nb0H1L X0o3IiaL/RSBgiAV0epHTnzNe6jP6YXfeshbVXNOhofCTmEhkY///Y9/vff+h7z/Rdgh45CU 3iiw705CbarbwU+3rZsrtHHHD4o3HllfsAhP4qk529jOPUjVOiD1ys5PP2EXPHJOL+wW7wRH YPX5vYf7E4Q0jK+NuNL1BhTlvH3dT2zIVRfdt1l03npR0YNm2biXffxVvkhMsTgpKiIsuuad f/z9nfc+XCPE+YRMSArfl9xbC69qKn0vyuOkrFXiQ/76kK66XHXRvZtERUVPylknPRyloA0+ Goe2bRIVFf1B7rSbQPElzM7MPHAVk90rKvTRB+//6x/vrBEVFpnf+eZ9azVzG4j9Ah+pvWFh doK3jZbWSS+WtVMBfe01OcrvHjW4jinNzAs3ld2m5NHAmYOeRW7J8j4o+v160ZOWmODrt7JM 93D2vPmUjnZi23w1vbW5XqZ7RD9Zu1Y2rOlmlK/XJe5QblO+GniPxL9bFrkly+ug6PfrOaW+ +fQzrbCmbk6UMjM99cDlhPQe0c2ndLSDi6ey1E7s2cTe846j2n4N6MLMuTbBzJRncMSs0oJi FoT7fe1TWWrHd389V9UiC+rOomhrgY8auwefrP10r8WtO/V9rOc5GSZ7OFXbp9Ytd6gXD/cn RkaeZ9710xLSvrXcKSC4Vmm4P4OihDteKgpbRYX/s+aDf/zln+//5+O5K3DDZ+uOW97uaOSf LqUn39NdYSv3EG5X1Q8p5p/hvb212l9VVPRrUVHRUzaOmLqRnvrnngf2b1knKiq6T9HR+/FK GpnveZl3t6Kipy4531x2TVzMnvqbHgdEv1vHqfDbdV/oRhLI3ZwiU6/QEocrkrv4t9YUXzO6 ICoqKrpWVPQHteCiEvLCwvNjoxYcOrd5BkUJt92V5beKfnfokHp6uvrOnbtERfdfcvbJxY+l qxza8ZUo+5+PUXTqFVpsf0Vyl+g3Z8QMQ2rH0i0O7Ziv97t1X+hGtVG6F+3TkuH+1PhczfyN DL9PWflAoq24Sj8VUdGv5iv87rCMPhal8L6YPzWOFtsbnN8lKvzxmg/e+b//e/cjofn76HeH N+pj26nLf42/tbDST5K3I1/sOSUW2MS7dMfk2FCx3YHzu0S/ETcyCr07dPPygW0b2beyPaeM gprQhct8/CIMHE9VoqKiomvXffmDzd37zQK/C6oLow0kRUVFP/tCVD7m1tNextO0ZMO5wT/j cCujAUVRFJ1+heJjXBSPbBUV/WLvmVNBTb3Iq+poPYNjoqKiX6z78pTtvV6eiidRtCha79xR no6fcbiV2ci/Z8Ldch9Jnq0M4vNk1x9Fv/lcVFT0jIpHZtkyezw7OzM5zCryU3ZxcvWfz9i7 85z9XKy0o58hAs9ypsdRfIyt+GUNi5iUlw/umX63QSkuu0pger3yXD97jU2n/YMkPz/hEny/ hX0KCoT70+ND+GhpHdtAz6xm3gfz069GRvAPW4IlPleMeUvh/iyKTo42xEUE+mt6cp4iEJ+k OhjwXS4HflIIyEdR7v/YhjoHK13kdm7+SuiD999775/vfMxT+NsfzpkHN6MDfA/3p1AUl+so J7uFW+6sU6SFXUKYOU/NTVnlsea77Mvue52XO8S+trZu/PZKXA9T4Pc0+NNajeE+Qu9Gyp1U tb3coh5wpovBYf2vOlto2QVhuAIDPfUuiSnapXdyp6Vl0pCW0pL8bEyEnb2m5JebFOxjEuLY xbPzsx/jOC9ft9cUZjicVLWOC4qery/pOsbniuYlDVP/9Ns8eWl3U/WTgrj4KGf5ry+YWihp 6CnLXTJ2wGCSMBgHbQ23wPjbywlXKZ24l0WYjDSMg+wx5ctqBsE8HcI+uM+XqXQ0lqUEa0ie 13a5Gh4/38Y4H0NJRQ1X//TylWa6FTddNNVOyBvmdXZTm/Od5C6rGmtEVc5v7W198Tg/zM5Z aqOkuuXhSzZmLtwx97iioKJsYB54ux5hMRFiw+MCjPNl84v7zqg7HJC39gmOYRe7ER9jf/n4 RRWngIwKTiMr4q942JmZevH0N8LTx0xLSsE8tKy3mYQgCELubHlxOybD7NDpM2f3/qSspG3v i8EkYzAYByUNKRUpi8RibgrZ3vA4OUhD8ry2q//c4MRdv+ZkKCkhtvXT78/p84X7xKaWygIM JgmD8dE9ekTdZOGCunQ6BV9TkBltcPTIseP7NEPuPe+mM1m9DY+T7WVP7/5izUnbGOzzVuKy p4pfJNxna7sRYGZ2+XJI8Wtz1aWs0nCfTiPjnt3JyE3HeOtLKIj9cNwck5DEPt5Z2KLK2m6E 88Zta9XdFJvzxxQtfEPmzhzMjTiMnZKcrLl94r0qbp1tjU9K7lzzDXO6uOG8g7WSnLaSuoqZ FwaTgMEYa6r5hyY9WebDLm4j5yTGY7wN1BQ0zENyVraccFmsnpudpZk3z+kd7uFlqiWjZMVd QJjc3lt7KyPdROrb7386ZeaUXotHGCykufqGmdahnd9tlVALLXrcyiAxOIWLMtJvcuq7fi3K VumorHlESnHjXBfy06P0Dp0+tHPnOT0Tv4TkFGMNCakzBxUu6zn4JcakeMucl/fySn6C5+z3 pLLMyfOGRnomfpjkFHYj3b1MlSQV1O1ySPWLrJn7s+F++8P71711Lpq4JyYncBoZG2mrdFTG IjKlWDCDXBq9G3kR56mvpKXv4BjC6XeAu5mmlpaNdWoDlZNJk9t7a++lp93EBGjJn5E8fNbI D4Nhdwhz+9HD2hUtqdH6tLI4j+f4Yfzt9HW0tHjX5iW1N9bmhacZ7z9+SnzfT5dV9B3n9msn ryypLmePuY8gyw6Gm7MTPRyN9R39MJhUzq3Rz9lYWeKsQ25lA+eoMBCk+WnhrbxwSwtTtS3n rcLUzl5QNLT2CMFgQqKizM+LR+VUEroQBKERe1vKbqfdTLeTVDbWOq5pbikhfVbLPSgqARPu 4OJor+jxYO73YNuDkgQHDWl5bfekqLlDGBsXZa8nflbDK5c9W8784FRVFufFepk5yG2VcAxT vnhBScPawgeDiYvCGJ2/HJiLebrsFZfpZHzzAxPDC7becQ+qe140FQQqHFV2SyutXLAiR091 do7DqQ/3umDKmlrxGYk+2if3akVU0QicJ/Vz4f5lWztb53AT2YMnjfKodUQEEQz326qzg93O n1BKJTzvXPBlg676xppKbAWeyVr+u+yLhPvcqXWi06oRBEEQJoIQ6x7evpPJc5IFWJqoa2rb R91smL8xkvEt1SW5N6IwXlL7xLQMrAJ4SucUVTW18K5G3na/KM5S9YKEvGVy+LW5I3gtwkb3 7IGdIqd0gzKKOCWzjQ0uHvt07wUJbefklFQMBoMJc3U3NlbSCcUymKtiGSKwmN97uI8Sc9Oj vM7rZfejKPuV0sHW8tIYUwmjoISUTOycNCzW2eiivFXAPb4lcpFO4stH2Mzr2CDZ/Ttl1awC 4uc/gK0gEOnckXmeoOXp5uEchuWK9/WzNFQx8EluR1nzf/hPjPT3VmNL7kbayenpS19yCNKR OKxsdS0xAYuN9vN1vGLGW3hJs7OztKbSyhJstIvllTP7LwZhb3A6dLcE+6y3f4Tzh/v47Ezb HW99Y0MrK19uJ+J9LC0NTQx8CtpRdEVRErnrRYK+6KcaUVWPu2ltRVH+Sqe+tiltIbNflXw1 NtjTfP9WvN4PeupKp7Xc5Yz9uLsOcrNUlTmvn/K4p28QHUV6m6vSQoNk1yppm51UdzN2CeeU DHMyNFDXNfS9y2kk+Xleloecigs2KW2+UEZyXqCRmqK+G6byKYM9ODO0xkcVETq2l09uO375 /Hlj9+upKVgsNtojXFdq0zGflFba/Awv4zPTrfmeekaGVtZ+7MG5hcVG+ljoKB7cuf+HvXzh /sTwTE/1o+ICLDbO30JT+aeFC+rOougQuaX6XqiFyfnv//dHy7giArl/4lVfb1N+uOkP/7Pm BxWj0HsLn7ssafFwH0XR4ReNhR4/fmaU1kxa4Zw1qzTcn0XRIXLz0yf3sCmRfqb7/3ZML8wj ln2882/nP6ojD3OSqZmpiZprV4wNr5i4RXCvwVAHF31jJavEMm7gNTzEwj29lVsQoSWtY3nx krG/tuJPqq4JyelYrJ+Pt4+pzb0OFF3Ol1m4jeSK8/YyN1Q3CcB0oCtYTri3OjPDQ1HNFZuS zjm9k3ICjC4r6HMXEJ6ZRmkNteWhjprnDm84cSms5jlrbBTto9ZiEo1Offa3DeI2yWnPqXNj P1e4mKeJ2BAHXX1jG9vkl3NdaKoqDDYxO7dp7R4pVZfEmFQ/bzsNyX0XL0iZeCbdTI2ztje3 Vra91zEzPUFtqC0PdbTUF9uraGUgZeybFJOKxWKx2PTEnADDy/LSZtGPShZZM/dnw/0x2nhz oqumlWtgzHX+RuoZ29qyw9TlopXfj3fUv6xjGoK9mcWuLykxxvmKlKx+ZOWzzvnIfmYapTY8 LyvCJvn6m8mu/0LRKS4Fwy5e+ODOc9Lw+PKX1BiiMHHlvKOdGh/hqHJC1iWHszbvzPQktf5+ WaiGudKp7cdVpKRNPZPTMFgsNsIlSFtm62n/jB7Wspfx7W8m3Is0kDb1ZVeFxWKx2NzsLG99 SRWb8Ov3eY9KH6XteXl6bIa//A5FFws1dStNTWVzfyw2B4t1MDMJC054TkZRdHYaHWxvfPKw MMI+0FJyi02wrYy8moatfcB1bHp8VqD2BbvbD17SURRFx6hjTQlO6oqGtkEBc4cwD4sN9zTR NLQM5syWwx4cRkt5XlZauPp2bSsLpSuW2peUNdywmEws1tfMwzfEgbfwL8ZqS7rh4WCkh6mY nhjrzgu1tLbxSi7oHhYoNv1quDtZSUrOzCS8lDLSTnrmcGGHjPO18loWb6nyXD8nnYO6N3DX VY/uNQgoKOhAUcFwf/TVcF2S4hGzgOxM3IJb3PjAZHdNSS2R1Lf8+dwWCfdRFJ2bWkfN+f78 v0dYxIbnvNd0Umik4xUZeYvoaiaR3e/J4UlmY2XR3YJYCwNtjRMKHjyl75aUvSQMoBOcJx+j 5JGGOAfVs2rG/p5Rc+cOFhvmYawg/r3Y6fMuWSg6N5pNWffdxd//5qd9F639IxOxWCw27Xqm n7HiRfdrFbi3MK8/+P1bheE+hdr99K6zgp7zjfgiPIIgCJOKEO5Gu1s7eV+7Wcab2uCbqlMj LXU0LTLyq9sElydtybsVbL5rn/Otth7iwt0SKsswV3X0jSKLiNyZ/ZlUBH8HE2pt7hR2FSPw ancXEZfrtHf3WQkJeQOngNg7TxGEgSAv8zFFRSVlK4qSlpxzv+dlXlbIFemLhu43azjLCzOp Pfg7Ia66ynrOYbErWo23o8zXQU/lgrL/XTxCYyIdt+xML6ue0YqtRhBO2tFVlZtj+O2ug4rn XW6m87yu/vJ2dLCZqoGpc1g1QmYgCII053oFq+7dctxAMay4smXuINBJXVXJLvbq8uZ+N9Lq EYROQp6m+jiYOIelF/COa3dtbWGku42Buuf9Ss6ivqRWJFH+wr6D285b2qaX49nvFb68fc1M V+WyeRgBIbPzPXxhUYKdtNwV97Tn9e3swaFQup/lBzvqHl2/V0JzsTn3aQhSFqEsaW61MNyf 016aGu1prmPu6pNWTaIyXubHBDsa6Jg5e2KekqgrmbLlteE+8jDZ3s5M0TWV54sLy7NKw32u x9EmLtqSahikZ9Ee4svvxbnLXFQyjyqpxc8ffVov8iQx0lBNzcbf4x7/i9CdFY2ZBtu3HZKU 1DZwuZFQWI8gNAR5gk2+U/yw7k3XpWaQEdxtD+kfVYx9g8qW+VlaD1KV7Glr7BKRVcjb5O7n z+6Eu9lcUfd8WN3ISfxoCFJ5K8LW3sDawS+7qIXMaLmT6mJhbmhpF5VZSEB+ZhVYWldTpd9P R8TNneIecfpbE6pgcPmSrENmIYHEYOV5nN1/5qSucVwFgdHJwvnrSNm4hRW8RBAE6UaQ61Zn j4sfUDLyybzH2RGx5tmdAGezS+fVs/KfdS543/5nwv3255mR4XYOJlH3XtIYnCNM7W6vvOFg Y2Thn3j3yfKOCpnUVpZvK62laeueWFrJ/Wx7TUG4v7m2oppXdh2tU+BcehbqpG9+yTDhyQpS 9aW05Pt56stsl42qJdO5uyU2IQnSp3Yd2Clj55RdSWDfoGrzIgy11LTsolqXNfU/A0Fwj0Ic 3J39/bIrCTwTpHTWleWHWqqrWcQX1TUKHJXGdIzv5a3fH1dWMjcJuFVU3YYgncSO0uv+eVXN /Ecw19xcU3yr2CUtQy+vrIbmThpCfFZdejcm/RmdwUKQ9pp03wBD9UtmMVn19K65HpJ7O8qw /hrqikaesfeq+BP79tIUjN7WLQeVL+iauCYVFTUiCJWIVF6/kf/08Uq+q0FFkIpcM10TExMt BwtXTaVzJlkFdV0LKmqpyvKzEzv8o9vD8mYSgjSXprob7tt9LrKuqpVzWObDfZ9rSY/irxmc OSB5LeVpW7tguN9YmhJo9ZOcVx2t5Q1mRFvEIuE+uRdfctvqkLR56o17ba/9YNuDayayKvJa NoX81/4vm3O/BRsSZa2kYHo1tpSzci+5p630lp+azBZJ01C+cF9LTvw7KdurmTVzTy+I1Q+v uZtKKVg8pjf+kVbd+WP5nYf7TFxeQKi7p3lK69wPBnDPbl9zsXYOLSHTBjnB2xiK1t+Ltnd2 vBaThxOc1XakF621lz5tfzX92SKv4Y31oQ3pnvbmATcf8y2v29/SeD/W181BO7iBSBf4478l 18lA/eixswbmTk43S8l9LBRltTY8z08rIaODy4+Slpxzf3KQRL7vYKytbxua/6CFGyv3N9/H Btvo65g4PqSQl78s7Cjp8cMEnW8269x43EMaRUcIhUV+Cmu+dcxtoXC+AjE7M9MSJqkne+6Y bojXvVbOZ1mt1cXhltoXpH2KOxv7UBRFR3rqa+w2nTqlKOF4M/UZN9bofXor1d3QyNAqtBFl jKEo6VkpJsDSwSutAUU44zoxMNNbjAm1svZNT33Akw1VhSXonVr/vZxM+P1qxtAoiqKs1tac YOlvD3uWtTaxh2uUMl0XZKZ3xTbszsO5tZdnUZTRXIIJ1j5zav+W18y5T6zC+NqLLwz354z0 1len+2pr6znGP3rRibBan5XEOuhq69hde1Db3rfIB5by2nAf7e6oSdIRkY1t6upYQb3oqg33 uRi4ymTpv6tENT5YtIcjzIkXN8101Iy9kwue8wRiPU+qrrlZahspZjV1D4xzfz4ziTaHWGvJ HvtJ0cAy1C29gdY/jqI9+JdVBVk1lBWsXiAAaSoJM9c+c9agBCULpotL6Xl6P9nfytkvoxHl Nnmif7L7XkqQhZVvZnop75vs3fgnSVG2pnpGMXn1fVRKc11elJ+RiZ5bZE5T38+vE9F9191Z X03MMJM63196RWKq6dGt8pEptX2U0fqSaNNL3x34yelhDWNkFCnMCPNSUbr2AkXHURRFK2/H GF/YdEzWIDKzfn5Hr5DJ7sLkQHVdk6iwzFaW4A5/Jtwf6e+qKnLUNw/MLcRReL9+0v0kO8nX 0d4zrpSKjrxmup/FzKAooynDK8DMyMAr+yGF89lhpLfybpC2mpJNFLaudZD/Q7Ty6hT773e4 3ulkruT6/FnDPS+e+h3ZdsojvhjHt9uKwAhNsS93KSlGP3qJjIyhKMpoabzpL7tDzPtZz8LQ +Gch3eVZaa72V6IfNbCrQlEURacnx/H5IVcdHAJv3H0hcFSG2ocrrE8dE5O8oGvqnnL9QQeK TqMorqKwrKyc/wi25JVdvSByVEZR1cYt4XF56yD6qm+i535i3gsCsR9Fh5GOR4X2sqp6vlFF hPmBnUFRekNhqJ+FyRWbhMdUdJTnCE6NDTYFnFSXljyhZGoVfj2rCR16haLdFc+rynOeLzh3 fhFiS25kiKaGfGiIv/ElHYvoiLsLT8LhV0NVNxSPKJjHRD6moOjQ2GCl/4ktKvY3kl7wHpby XD8nneM2N8fa7l2V1lHzdEuu6xQM9wfHBsv9j5/3xTwoHxTczRtZJNyfQVF6400rV3sPk4TX 3+OHu5qwgdo7Nmpjup4LPBf6BXPuDxFfVgfIqhnY+OU0vaRw9kurLwh2kVNSkOEL94vcL/xj +yWjqMdN3QMoiqKvWKOE235S4vZJD4tgVRSwOsJ9h/MfHNWLiotMY0tITHC/ckHTF1M+F5rT iEiRhcIlAzVjvzRBCdfj3BSOqATllNUIvO33s+E+5UFkisPFzYp+126kLqjTycjIRtsoBceX FnURcdlOe78+puEVXPB2lqRbMtyvy/AJMlM4H17XSRaMrVpuGtvY2GqGPFnmPlkI0n3fS1pZ RU8xaP5V/ZaboXqXpc4YB+MQ0vx+uqpyMwy3fXLENaqkXuDJRfsd/0R3HZnY7k4yC0GQ5lwv b7XjGy5E3O8kC+QDLQnaHt5XbbJJrB5Cd9R5KXVzDafoBaMdERtrfOiQa1rRy7mHLKRWJFH+ 7HFNdf+8Sp7aymK9Ak21XCsQ9nvNxILARDftk/51XQsGp8jtrLqW/srCfQRB2ktTEtx1xdSc rieleF6RM7D1DlzWVzP4vT7cr8nxdHfR+fOG+5SS0HgXnZ2WxUTygqcmZT4OVnaX7HO7eeeD 7qxoTNfbvn6Hll9x0YrnP5nHopGJNQV3b2XynosO0t9dMnR1u7vMqojNxIiz59QstV1iFpze 4dHRJgcOuGU9bOB/+lh2K9zWUlnPxPt6ire+qryVW2JRlWDFZCrpRWlWRg6nsuS4NF/ZQ4f0 LebyegRBkJpQBRefMI+7CIJQEeRxqIK4uW1Y/EtkLs1XcLzKG+4f2ievHhAmuKcmXF2cyjb9 +JLnC162/5lwvyzFzlhP/LJVWtrCe2iQtpSxa1hQ6bIiQwKhLvnK1qOuyY9LBd8Cb3uWF+oh cUwvl/RcYNPbDPfbGp+UFPB2I9LaSlN513GvQhKNe/iITUiC9LHD2nrhd3hnZHsU7uRvecXr CbKcOV1ICHLX55yMvp6l24IxTI6N9JHZrx12N+cl/++2xnSMu+KO78VtsikNP/+6fK65sdz5 Q6pXMQ2LPjR6nORoaq7mECu4lYYgLxK1xa1cImOq+T7QXpqSosJv/eUAACAASURBVLPz0+02 QaWNTb+8lz+vNMrb+MyevT8ePWUTXkXneRl/XtetjKt6P32r4P2E1kJBEATBF1+PUd/2uVIK tqZj/tbCCffT7nXX1ud4nVv7g+GNwuJO2oJwP8JWTDeGSpub+IvU3l1blJGezhn2rLz8+43M ZS+G0piW7Kq9e4eqRyrmxlxN1+KjHHTPnLa+9vQ+z2D11j96VJDFe6C9tMVULynqpq8g3G/N c7dyNbIOa0D4FiBAaAhSm+kamHb7AfcAZhsbWLioBpfylmt/lJxpd1oilv7s9U8fwG/r9xbu n9c2cAvM54j2s7Jx90rJ75kvRUhLvWq6/4Jr/iKiHfQtHNwSywXyuJ8N96cY+IGY4yc03KyD MAsqvHbtmu2+ff5leBr/ILbkOqkqn1O6FP/8rfR8yXB/qLux1Gizgv+9O02COcRAA7bQX3Gz 8eOmnuXOPjFKfBgbrnlY1KC0sWeYXVdLnsvRd/c7lRDq5zvMDvfl5fTUAh8KzH0wTm5q9d6t FvG8oGUCnQ/3t511vnqniSHQyNrMkqtKYrEDbczp0dKAGEfNA/rRC0b7dn6+i66uu8vVEu6y x1Vh10xUd0iHlXKCCRRltdanSn3rXtDynImiKDpBbuz2/1HW58GtOsHB6Sy5FqaxZ2XhPoqi 44wOQqKuop6DV9iNhCA3e0NV/eT23pUuQvj6cJ/e/RLrsEU2Af8nDfenqE30qFMHzTIzny4I lnofPkux+PxM3LPOPu479Oxw/5L4eVW/xDealWrOKKWlpaqI71bipGUodeBiGrrcqZJGH/iG O2gfMYxZcHrfys931tb28Ah+yH919PY0pXqcv2DmmXwtxNvb3EaX75sKbDMoSut4UVHKW1+8 jamGtpjStRcoyj5C9IrEXE8luXR2mzsrEj3tJZVcXqCMcRRFK28nhhnzhvvBunLfS5qUoVS+ K2MKRR9EWXr5+eQumHbqZ8L93raqG0ZfHLaIS4xf0O0UP0fPK1p6hQOU4V8+ofc0ij5LNDdy tonIEZwoZGxirDHl8nH78Pxcga8XvM1wf2iIha/Oz7/L6UZmXLa//I69lkH5dXy3wYrAEAO1 fZeiy3lmjaM1VifL7XQt7qxbXjtaHkR7mByTt8nPz1gwjPFWGvau/ler+H+3DbUPl1uf2nlA y+veYl+24K07r9RD+uPv1QPKqJ2L/KLoIVTdMNl+NrCMRBDcSq296eunrmJVgTJ47gTscF/u rJZ28P1lz1D2Ot1PahIMDx7+bvcuFcfkmkWeEYwTh1p8ZL89axn5sIKFoig6NTrw1GmvtJaL U2YLzyXDDvedM6cnhok5vopKWqaBST0jC8L9Sv/jalF3K+a+VzIzhVLrn5eX8A57eSO5d7mT pQ229ZfaHN91ycgtIpF77Ud4GmvYut/gnc7tFYvYVcu3u6RQd7MjH8pGdVQKzI21dLg/1PU0 3//4MZ8qMk7weSS1sfB2RgimYu7aR9GmrPuhBp/q3iUyuBf/1Gh/49Wf7KLupazoazbgD2Y1 hPtGJ/73H2vWrPlYSEhIaM1HH7zz4UciJ/xxDzjT9JA7kKRLYjvX//u9j4QWISoktEslpPCu QPj0s+F+S56Pl/Tnf/v3R2v+85/F6tx3VMEnE0F4coYuIu62096LQfkPK95Sz5cM98vjfAJN NF0qkN6F87Y8j/Tx9NZ0urO8XfbREPr9kEt75ORNzFM4a/QVJdjJKJ84JZ9A7aLMJQRdVbnZ 5nt3mGMLahYMXllsbqDJAdeK9l46giDNuV5B5rKcf/LB2np5eWvFvqB1tZQ77tm3SejdD9Ys NtqfCwnJ2mMr5mIIUiuSKK/sdD0Ai+PfLV+4XxZj5qp1TiUF6V4wU87ziAVz7s/5ReE+gjDb yzOSVD5b894/RSV9/PKa3iQ0fH24X53l7uqo9ecN95uz3WNcdNUwyGI52q1od08z3bhK3sS2 s6Ixz2a7dPS9sjftL4tB7a4vu2W+98CWtbxn5Af/+ts2uWWH+9T2+sd223d99brTe52QkJzT 3SrBiI5+Pz9G48Bf3//XX48aZ5WVCz7goNMoT6pLHGREP/2SU+t/1gh99O9/rJPXX3m4r2rt nrqgfx1tdTm226RCSioXPGD4mXA/L8LwzJ6/v/O+kNCi99DN5y1tMMt6CFPXXBchvdUiueTl wimAOspu5tgcuxBDElz24u2E++y1apMC9M7u+5CnDx+//77ItvXHve4uCPdlHZIj+H/lrCjc JyJIgvn+b7955/0PFxtDISGhbVqxCff5k9fGdEyk63GtNMqS3yXKNXf0CLhy/eVrNueEOXpY Xrn+ZLFZ158Fyzj5Rnrf4/the2lKlu1JyRhKVeuCD7yBxjT7CFdj7bTFh45eFBiqd+HTw3Zp 9U217F9ZJUm37c7+vy/1A4pftsw1nSfcRxBiU1Wqyn9OaF0NwzZW5QmE++G2JzUje2mt7N91 DYVP/c5/9omIkJCQ0Ifvvvfvf76/Ybd8AvV5+yIt+fk+JNuKr/9/73z0H+7lsOH7AwrXaZyq 2CsGF3vJyP647mOeQ/zhu//86vDKwv2cYK0reoq+Gb9k3vxsYzv3IJNEvlcTINxf/X5v4f6m b9778CNhYWFhIWHhj9/9+193a8VG8k7T8zQyVmfv//3rQ+HFbT2u7ne9lb/inw33R3oba+03 fbtB+P2PhBar8GthYbWQeiL/d9Vbcp3c/J2jC99Sz5cM91ltjakXNrvfaaoR/FYCijKeNua7 b5bCNC33dfLptspkK/0D289EUavnFqBsqn0QZrzxfyS9nxbi597SZIf7uvYBzrcWzMXNap1J vSDpXpBZw0TZ4b79ZjH7nMyFrSTcrY8zYIfsxBwHu3Of//29Na85gicu2iRz1y6oCsOEe8hG 4fh3yxfuM/FVKVJ/VY18eX9BvMWoWjDnPtfS4T6KzsxOj730P3Nh+0cf75aXDq3nXdV5uV4f 7tO6X+TabJaNx/1Jw/1h4otqh63aCYSHi2zF417EyWx1LiTQuFkfO9x3ivSIq3nDhs3Ozk6N IPVJFubiG3nPyDUfvPv5lpWE+12Z1pZnPv/Ha0/vk4pOmFKBz8zQxvuidb5b//lfd5w2iskX fHg0Mzs7NMjE+Cqf/OFj3ia+//7aA7tXHu67aB2yT0dR/v7NoGhThqVjoE9CsWDPfibcb2l6 7Hzuf/4huuY/i3Z7/c4TJwIaiaxxwc+91iSK5gea+/n48M2yxjb9aqQp6P+3d99xTWXr3sDn /dx73/fUe86cMwPjNMs0z4xl7L03FBGxIFIERBGQLiDSe1MREERAQAQMRUEIvYsFROklhIQS QnqyKFKk7vePhLAToohn5ogzz/e/Ya+stfbaO+D8srMeBfsQYqTUPH6xcH94qL/iaZqN0t/k F4j/Jsh9IvfJ3//vt4Ze08L9yEAfrQiJab5ruP8o9bLWtv/589/k5WX+KfrhgLFJvOQ7pI/6 8qnDvtNRGaUzbQ3flFoWZr7Stfo1V6GxtixMdaVrfgd/+pRZDyPueZ46mShR6kAY7tvdyPhF Pl0T66U8eeKwWjeqQ+Ze92NdVayQA4tWG9rHF1UJ/2TRWlm3tZT2n1H3IjZMfbFgMtzHsJcY Vh6ibaGvrX29StDdnaqPD/cfX96ldZ1YWimqtzuA5VifPfCzvLy8/Kf/lPvf//dff/jf7dYp 0iUH3uIcuossd339+byP//kp7vIpOBDxXY0O9lKzgq6qL8a/pz/958ef/OPjfQHvEO43VOde Pf6xZng75zU1M/Btkx+FWa51r+nCfVAN4T7AmwvhvrPKp0fcS54WNzY2NpYQoy7qLflMyX9a uK910ejKg0YZmhobya10FksqF5gp3Pc3VVpt+eDx81pZfZJbWjuZ+KeGfxvhPoeGytzPbPpm 3h//8pd/iGv0ffLxX//4py9XLjqbLN5T/tcI9w8aejpGP3zNFaTSWBzR699/uE8qT/W6sOzP +3Zs/XSlkUFg1rQ6vrPw+nCfGH7B8txhCPffQ7jfXp6WZLnt6xX67gm5pbgbMdJwnYHlO4b7 +w193O6UvuH2lg5in4RHWSv9fcHG7Qv+dMgl/a50Jd8n+XHmJxf/pOhRkS7utfpp431j5b1m F+dKuG+kq2gT0tgo83coidoh4zsZb/Iew/1OhO46K646csLRPg53DkU3b9gbbZD15P4vGu6r mdoEx8taw8bGxua2LoZUj7+zcL80xEh/zR//6//99R/yk5W5P/3HJ3/960f//aPWjZLJDz4k wn0+j8povWq8WUHfKtInVCrc97bctt+6iFUn/FYJl8XppDY1NTU2NjYmuXmba32vHdHUwX3D 7livO4c77iabtl1KqK1/IX4LNJNbGQJxV8yWqseumzdtPWV0hZCPu8RJruqWehDuA9k+tHBf 3dYnPoPBYDCoDEaO54HvNCymhfvO55foxzFkY3EFvf1Su3K8Rbi/2zwiNLNeVodMBkPQNzwq uaXEbyLcpxOTnJR++L//84e/z5MTFaCUl//073/57//zB4WrUUXtwla/RrjvZaWn6PXwNVeQ y+/un8qf3nO4PzA+WnXz2OJTW5f+tEVnhWZk3WSQ+g5eH+63kMtDVP947EYthPvTD/664f74 6CtyhKa68ikNx9hS3F348LaLh9Y7hvtuVvqHfUtfe3v3DEin9/zmgYQTP2848PM385W1rZyl K/nyXw0S7Lf9qGpwMzAb11P5zQDbCwfnSrjvf/RPyr4PX5TL/B3K5nL7RkbH3v5zsfcb7ldk h+prrd+jepNRRZ48B3IZNc1022bbwF833LfT3WB2k8Egy1xGLkJSexv9zsJ9Tl1h7NE/fPa3 P//1H5/Ki+rFfjbv4z/94Q+LNp++Fjv1CbxEuP/qZQ7B01Bju7Hvs+4YXXy4X3p513aHm9l5 wu8LTYxjQ90CLovBYDCq85uuHfz6iF9kPmVgtpt89VK6H17atcHMJ76wEv/O7xnEd9WR4nDp 1PHt2gH5DEb7ZJuqvLvXDn188iaE++A9mwvhPn7PfWYn5VFRvKuZyhnf+MeibXl4dNR05byy 8QW3hCdv7EvCm7flqbhz18tgrXJwYWvX2+0c8R7C/ZoEb38LNeVgmdvymF28aKsXMIv1QAix Okg5l1YrqRno24fES/B2s9XZtkTjWmG7sLBte1lKoumqz0+GpzySztlaMy7fdpfclsfw4HcG 91umpexT2/IwqB339dXUHexDC2fOZd8u3O/IvBLtcnbv5VrZ2/KcfedteZpK4lzcDDT1nBIy svKSfS1Nztsa+hNr3zU6fG24/8jX0fzCcYt40tvkMjJ94OE+My/wlrP+Kut8GRHwI29760vq l6Zty/PLhPvUF+mRngePGCcWl7TS8XdtqvUWM+tZh/u8LnJHst6xE47OEcVvW4u3NCz4krnW efcrDzJyH3g7nFazdI2JxSfrVbH3Ak136V7PqGRPvbFYVPTQVk3R0vbdw31FffPQOOlZNpJq IrRnvS1PS7qP8UWd0xcLEPNdqlFMRybXxBgv3eFy5+FDWdvyeCjtOPcrbcvT1YyyDLXOOTiG FUvU4q1PvOtjuflXDPe5CDXe0t1tbucfXD5z68lZ/VLh/pu25Yl5zbY8/+lwvyH52tlTxxS1 rMQFk4WFt29c81RZvOFc4I1s4ZY3EuE+QhyEGlOslFR1rA/pWuDCfUZDdnjI6R3bvMufkKZt AFQUeMPBYPG5BOZsLqH4HGQU1JVAo1ZnXN620+JG4v36VnxN3MJrZxwM3i3cL4m2PHnmyDmH ojfV6hCBcP/D9KGF++I998cwrLut4k7opYtuXnEZ4kAF5aYGOR7Z412CYW+7Dc2bt+Xpbusm 6hxS9Q0mSm8m83r/6XC/j1ZfbLL4pMxteerTsi+rv8O2PM3Jdm4GyrsNQtIkxD14YHlozTHb a7miwrbCbXkM7E2jpHdfGGI0ULyltuVZ/PPp0NvF0svcU5lUIN6Wpzbqlru1kkHSWxUBfotw f5hR33F54zHvwrRaWdvy6K1913C/h9uWG2O43dDuVvS9kuKkiJuXjLefjy3uQu+2RfNrw/2u khd3LL7afLWYwn3H9+oHHu4Lt+XZYpGUVD6tBGlXUUWc1XyZ2/L8AuH+4OgwKU5b0+na7QQy C7+bBSn9WqDeO23LUx0e6mqjYnzvbev60p81xjsfVjF3T8rLKIyNuWJpaXDRrxTjiW+FHupQ wflj+j7XHzTR8FWc2xJve9gpv3u4f0FrzZnLrRhfYpajGFYYauXp650yLeJ7Q7jf11mV7rv1 G7PklmezriErk3hbnpAUWdvyxJ36NbflaYq6c83upG3Siy5sqhZvX2v/E7t92+yCfsVwX1AR 5+128ojlI4z9lmVcf7FwH7ctj/SmLuxKwmu35fmPhvuooTrBS3nhNpOI27ck/2iFXziudcZE O7x2sqlEuI9h/KYHVzy0lJdeyAg+Pm8y3B8ZGaAXWu845xYd9mTaBkCsmu7o4ws1whJlfsgw 0znILqg7ZQzDOrKcrD3sfK5X0XowTLxfFbM6N/r4xxph7xDu00glQcbfLzZK7qya8d8xEO6D mcy1cB8hxGTRn2UEGtoY+wUSntQihBAHoTKivanVaSvLW1nluLqviEmhV96/7uofn1dTLVVR 980FdWlVZckBpiqqpz0IxBrJYrw1melRkdduZeELzP464b6KoYGx5V3xc+E1T9KjgjwCPO8+ o7O4CCFaVUrSNYvj6i4JFXSqOODjMFB5nK/paQOnwNDZVfKldTSnOa5bqGoTGfVYarGay1Kv mKz816FrT4obWQih9rKUpPM/LdisruGakFmGy7BqMuIDHC44XY4rFyV6jSmePtprv9p13iwk v5I02S2nC5XH+dibOQsr6PKYqDnjusU5g/POXkmPyfg4u6OhIz/SzSkytZIkGubtwn1Eysq9 ZXvspEVofidu2I6yODezfQvXv0tBXTZCZRlhjg5G5y2dIuLLEYuLUHVair+9qb6liTehoIsl XbT5LcgI93lM1JwZf0Hf0MbXVfpbAR309vxYVyc3W1u3G0nJby6Y/JbhfjUx9Zafra2Ti2fo /RpW67QvOkj4TxbUJZVmh7uqaujdLOxqFudhXAZqzoiz1De86OeWLbk4v1i43/A46bLlxp0X 8miVonE7Oltz77g4nt40/+CZWYf7wmK8AaZnDYzdfO89acHf3u11rbmRLo6RadXkFlHbjuaM gEArQyNrX++kx2TE5SNScYyDu6WxiX3YzdwWtjClK7lxx/ns0tPxLyZLuTLJz5/FOzud3bpk lZ75O4f7B3YqbtE09b2X1yJOA2nk5/fjvM6ftkjKqZpVQV3UVBIS5qJxQtsvrIhFnnolF6Hm ktiAiOh792dXUZfRRXmYZnP4jGXozew6/CtJD6PDXfTVtd2Sqn+dgrrCGrmnvJzjy8XjUovv 3PHQOqaotPRX3JYHIYQqUy+4mJ8xsL2T9Bwf0TK62sqJ/g7XCSWlUhV1f7Fwn1JB8L5sYXba K6+Ww5sqidzR9PS2/jktY/eb2VIX8D8f7lPvWeir6h41ja6Q/BCU017bFK68bbvhxZu59QhN C/cRQohSeNXhvOb2FSuUNi5WvCEM9xGjqbgo0uTQIV2/xKrnknvvdKR7eZtr/GrhPrX5eZzV 4n9Z3i7JFY3LROhJ6nU/s/0rlVReE+4rnLG+ki4ua0wtirkd4Hf1Vmo+BfEFCCHKs3g7N70T Svq3Uup5HeJLyKEjUnqMv2dIXEG+eLt/CPc/TB9suC/EbSq8GebiYueZO/nQNJ2SG3lDXfeo a0IOQyARnvAqihPj4hKLK6QeHH9zQd3hXoyRH2Ry1vRSUHixZDFeAZVRmuDqmlDKRJIpzS8e 7kcHaG7cFlBPFlXuFQgYpQmubr4xpZWtAgzDhnvpXXm2Jmftgu49b8anjV0VD6M8zuubXspn dM2iku8EhlFSHE4ZqhtYZUklAQPj49VByut0LwSHPuvBJsN9jWNK2w2CIvD7OvMp7fnhBvr6 4YWdVFxB3bX71FWdEjJf4IridlWUxF+xdpisoNvdWEa4Zn3KwOhGURWvbyrFmhjHKLlptxNi M19MDfMW4T42wByrvmJuaOYV8wQ/LP1ZWtQFxf0b362gLp3y/G64vbG+vnN4IYsqwDAeuTM3 1PGs/nmHW4lVbYzpr5iJ7HC/u6ku4ZrnWePjCXXt3fh5jGNYy7MH0TddXT39Q0OLmbyXr7++ bxnu81s6S6JdXV1dXQMJJSTym2Pr/2hBXe5wZayZvq7PnZJK/Mp2N9YS/D31TVQT6mjd0wrq /gLh/suRV2XXDuyyu/6AKBp3HMPI5anR7uoKR/a8S7iPoYbHcVestI1MbpbUCvqnbrvxUYyc lRqdEJ9TJV6D7sa8vFBnO/NLhiFFNYKXAxiiVd8neJ/XN/K8ktrYLLwvOY0DMUc3nroRXtIm /FRpYmyEW3433ktLRVFt+zuH+6Emh3/Ycdzk5r06NHn/D4+N0Mri7TzcIqMyyNO+ffOGcB97 yWl4fufoGZ1LPvG11fiCwVg3rTqXGBUWVsKSfur8TcYxjFNP8LhyycXmViULw8SvfMkhv4gz OKtlc+NBtfQN/EuF+4+vBjvbKDjkicd9SauqTHB2OLv9258tLv+K4T7GbXrwIFDrmLpPRDEf 90HOOIZxG3LjkgmpD6Qq6v5i4f5LAbUo0/a4jl0KsZaN//CS9jTihrOZsU1EMVNGQd3/ZLj/ sjElxV1j/mq3rA5+t+Qh9NDPw0hvr25Uo+gTNalwH3vZ/jAnzHTLxkOHf/qzir0w3MfGRwbZ j/3crEwuXU0pltx37xXtOenyzq/VQn+dcH8Uw+rjTU7ZXbwaNTUurenxvUDDU0dXfHw4WFa4 72xxWDOglI0NjmIYhr3sqKy4H+zpcyuL3MsZxDDsJb8lO91mp6Kab1AWlYq/hKi+MjsmPDQ2 pRHrF36SB+E+mMl7Dfe7GmoehV+20tj49+36NyJCUoof1VC6EEKIjVBOpL7hBaNLrmk5OS9o bC4fPY4MtzY4rm5mTyDcEZeii7we6Xz28EEd5/hHj1oREu6m/SI7Jy2JcMPe4ezhb3846RAe HUkgEAiEJHFXCCGE6PWlRf46Rw+dveAXLFHm1dPU7JSh1qWoXOF+KV0N1Y9yUgiRkaGOat9v PuPk5SdslpBMSHtaTaW/OSx9g8e3TAw1jyhqO00O7GhreHL/HgM179z2LuH/prfWPYwNPKNi 5B4dHCkusxhFsNdS0/dwT3g0i4yT1kh6Ghceorf1fxcoaDs53srJfdxAQ4iPUFf9o9Lse8Hu F06v+9sCJTunkMzHNdTGspQU4582HVBfe8TcwuXa1OJ4mJhe8rKInvrGQGOKZ9CZtT8rnF53 3MonIEzULCaSYK91wu7mDVx43ZTq7W2ip3HW3g9fgTP0ariF+o4DtgFFlbUIMdtI1RlhSZZb dqiZnXZLyH3SQEM8PiI9z8+4bnxK79BeDf/7SY8orXQuQtS6kshrp/doWEfhhg2309xx4Gf5 xRsV95pF3M+tpHB4XHp9VWl2CoFAIMQSCD4GO9YdPqJnHCB6SWpxTS2VhTidzObCrOQLJ5Z/ vXr9CU2/3NxKGofHp9eXlt40t9i/+q+f7NYLT0itaaXO4npTGp4V3nE1P7vpkw3nwn3EN1ls NMHnvK6atXNU9rSCyHXkGi/Vv//pk48++scmPRkhO5eFmh7mEe8TCATCLb8Qh6PfbDRyEXad lJ6SW0nl8KQDvwcXzRS++eijP/9t3lbDtPYXNOkumS1VlUUpornZH9XQ0tlnHCj6z+zyF6TZ fqLBYHVVPbyXdJ9A8DY6dHLf+l1WhOhYYXfErOLKZlxI11KWdtdun+bF24HhuNvbx0jnhLVL dI54ceh1Dx9m3SPc8gu2P7pog5Hr5FImJKeklVHbumb73Di1pij0iu5W5fPR/qKeQiNCzTW2 7V8//x8rdqufupyXV9XJlaxQOaPG+x4e5/U0DRz8CIR48e1943Kouca2/Zeul9bUIcRobXyW ct1PdeGiH3YqnL0cU1zVjLh81FSRG+6mvmXLkmVLtQOjs2soNBaqepDqa77rwFm3mNgoAoFA IEQEejlq7ziw6ZvPF+4+pH8lpvhZPaP5WWZSqOGWk9r6mj7ZaY9rubySQLXd2if1LSLz8qoa ubxI68N65/U9I/OeVnXSeIIoa7Wjh9buOKlpYH6ZECuaZUig1yUTdevgJ8xm4ePEjFZ6VV5y orDEqLezycnNn+0xjIoRFgtOzS553Ix4oktY+YToba20X80q5nqE+JzvEAg+Ntqqpy0DAjPf 9psMIhwaqgp3N7C0dvALJEy5YmdoamJsHVvL4vAnGzaTHj9ISiAQ/M+q7T+8TdH08uSy3897 WtY0q0K+CHVRUabLGbXTehc9xeP625w6rbRyxdKVXy/Xdbmd85Da2YkQg9pQ+SAk0XzjJlVL A6/k/LKmTsQVoKZnOekB59ROHzmoHfDg/tPW9tntR/QwJdDMVE1Hz4kQN3XrRETedDA4sF/X /V5qWTtCiMfu6qjIyExNJATbWBmoL99rHXNH1DqZmJ9f3cnji+5YBrWhMpeQmEAg2B0+oXn6 oFmQuFPiw+oqfF5PKci75amvauERGzdZBpYQHR5ie3LLWe+kVFGozEOoo7YkI+seIcL7gu2x n9edj7ki+pWbfO9Bflkrb3anK8JmdTVVEBNTEwnB1qoG6kr7rAmx8QRCTkU1mS4+GnJu44bt CltOuSalpBfU8zrZCKF2asPj3JibCd5HNs7fpKBt45eampubmpBgqvzDjmPaNq7JxLSC6jY+ n4saCvzPaC/53798vlghRBTuI0RrbySGndly1sLfY2phCAQCIdjN3NTUVO9aIXuWm/LQa4uL Y+0stQ4vERfUvZ9XUN7UKbGzH629Me2m3gpNw8vOV0UrVKFYDQAAIABJREFUTSDYGqiobP32 q5/Xbj3gkJZa1jb1NSZ2O6q86aKyV1XHynxynleNj55UPqxxKeSuuIJuS35OuK3uETV9j/ib 4ksYE0HwPqd5XOmsJ+HuM8Rh0BqLEtKclI5r6h2yik4rqG7jC7iI3vy8+MFVy4vHV649H+ef /LyG/JpPJcB79WGE+8PdfV2Pi4hWR7/drWHkejX7YfHz9h5RttJcee+6ywE9KyIxtYbO6B7G GJWUuw6KmzWtI2KiJIpg2lvrG5p6xmZMVt8dZDWTnuUR790mBhzfuOq4ro2/uH2BsKtJnUQP T1MjfWtfiTKvUQER1mc2K7rfpTAZGIYNd/fSa4qIxExiqP0JjdMnjaaq+uY9e9HMkn7k8a0x Kh/ctlH4brdVaORdIpFIJIZF3zyvvOLgwQuJOVXCqGxoYryF6GHg6nLZF3/O153crW21PDPe 6il40VL3T9ArSgs8DfZu3b3xpGFYHrGY1NU3NIxhr1AXvbogPT3NWXnh1gMnTrrcL3nR3j0+ Xh+kbHbq0LojFsdN/aaGjrwW7mKx1aOkZfK8heH+4WMaG1RtTFxC8JN0c/U8i9tEo6e5pPCa wcFDpu63705VMU5PI/oaG2lbXQjJqsSwiYlxTsPDpyHnrM5pbjofnVHc3NU3NIwhTnt1Ttj1 Cxu+0nC+caOgmcwaxLCh8TEy0V3dxsZTYlhHI709i9csX/zVicAbyRXNzO7BV6ins7qISMwk EonEyCtW2sdXbz4RQLxzj0gkEnNKX7zoeIlNTGB9baSKcG/DXevn/bDROuPuEwaze/gVonc+ jHlguX7BJ+v3mV6OfEHumMX1fvkSkZ89SHU/tEBZy9TYH3cFI328L9ictYx6iKsYjGEYho1h WGag9pZlH330h8+XLHGsap7+EQRqa69+KFq6G/rHThpoiLrOIBbUkpk90i8gZz5x3vLRRx99 9NGCgy4p6Z3S/Y0O9qCmosLcTCKRSLzpHGBy8OsTAWGx94lEIrGw/HHTW3+zRWQCw9ht1U9K iMS4UD/Ljf+z0zDYM0J42jkZmS8ovYPi7Ht89FVF2CkXV2/XEPzieHtbXtS3in44WWD2FaLT qguI6Q+IN84eVTPQNLk29RasILfM+nOIwbGRpgcuSiZm7naintKIRB8Hg1P7l/y4cumPmy9m JpQxWT1v9Qi+WHdTQd5Vg0OHzT3uEO6K55eWSvQxMjhlbROeW4Vh42Nj7PriFOcjKptXL9xm cT2rsqlvcAATsFuLU6+ZHv3qf749aOtw+2kDrRvr6RzKc9M8ds7SNyRa2NOD1BBbrTOHVi5f tuGn7ZbXs1409XGpjc9yAszttLZvuZgZXUCl8xsf33a22L79ZFBmygsmq6ckPcJNe7tZUObD F8z+nuEn6bdtjyzfefLQYSPP2HDRLJMepPrbapr4J5SLNtYaH8PY9VWPhTU/Y1PuWSh+ueOU pXeA8CbLzCqjvuSLLmH38GBu6DkVI2Mf9xv436G3gj0tzuuamsa3znYZMXZpfoSfhb5TIJF4 f7K7u5EhTtq7jW48ejZZFnZifLSvtby8JJsY63vV8viCRepOt+KFJ5RVUPqQ3DMw/PaFfDEM w7DGVIKnlYqmdSCRmCI88+sezro7FTZ9/+mCQ7qOMVmNnVwMGx8bYdcVPQ7SM9XX2WEek1VK Zg0MD2MCFrUqM/iq5ZZv1N1vhRW1UDizuic7O+qiXQ/tOn0xJiRm6tYhEkM8zfSMLK/654ri 4gFGQ0NZLjEpIunyiRV7zJx9IkVtM7MK61jsXtFSj4+NsOsKH+cTiTfsrxgf+kY9KPKu8JyI ucVPKxnYkDivH2AO1kc56Fi5XYu4TZwSaHfWysFLPC6GDfBpDVX5xLT7iSGnf1Y1dDYPJIp+ 5xALn1PYsztdkQkM6+tqKHuaS0wM9/M78e1us0jfKCKx6FlZM098NMvfxFBp5Z+3XQyPSXpU z+jswTBsaHSEVluYmx9hbaKksHK52qWMjOKysvz8QDsdNYXlahczMpMK6yic3kEMMasJofvk Pv3Tf60xEYX7wifoS8ItXS2tLlzF37TExNuhl02PHnN5UNrIeePMpb3id7Q/vpPgfXz5j8cN hQV1swqyH7WwB4dxn82OYVhHyU1DexNTIw/xmAF+9ucOr1y34uu/rDsXEZRFpXJxH8OwSrIv m5xWVNUMIgov4J0rjpc0Duw6bhH8jC/6SzTA6K+NsNM6cf5SoD/+EkZ4uJtraZx3uPIY6x7C BNQXL2Jsfc8f/l4r5HZaFZXTN4QN9Qva67ITwk4vO27kahlZUTb9oz3wO/New/2aqCDj/UvE deWWnjIOypx6rizHy01z/YI1ivt9y6h0LkIINWdm+Z9aJSc3b6oW3U/fLjEMJneIY25OJ6XM R2H/6vnTKxNKdCXEaEWJBqrbfpRot/SU6fWsGtwkA8/jJik2b6HcqguBuZXTH2h9a9UZgee1 cF2v13L3yZVq09TaFKS/eNG/8OOutpr1uE9jkmz2TI30g+JB89vC70BUR503Uvged/raZiHZ pWUpaTabjt2gxngaSR7VMQvJxj/715jiGe6kd/JGc67L3r2rJpf980Vyq62C8qqkJ/k0JsF6 t+RVWffjQb/MdoYwQm4sSgg8IrfwC9EklSxiyhGDiwjuR7asE3X842rrzLwqYfOOjuZUrz3f 4Ib9cbV1ZoTjKYN93031XB3pb7BPxhUUnVDQjRwy6qgg3Tff883X80WTUlK6XN7O4FbfMjDY 952wbzm51brB+TmzWPes245qu2SM+bWc3DF74pNnMl7SSKkPOPPdgsVycj8cNL9wZ9pu/10U RDijsnmxjF4Xrv9J6XI2jSkdxme52Z9YKye38NulyjbZNOkvuCBESr/ip/Ga5VFw8El4w6YQ MjW01F4TnsI0G/ecupyMEK44Q3t74z2PnQtXfC1uM19OTtUh4yl+1KqIc/p7vpve3effLl19 Maew5h2+UNFArvbX+2b+5CQXfrvs8MWczpvWSqpr5BZuOHz46rNO5uyf3n0cFWuxU/KibFh2 +GpOJ1MYm9Xnx/oflvvqc9Fq7NW5eg/ROeiui9LGNaKz/5ecanhWWQtCqL0sNdls5fwvPhN1 tXTvasNbnYXO+jt//k5u014dp1sNyc7b5//89eRRs7udjIfh+jv3fCe3cIPKEf8iOivWRWnj GrnFG1Ss/Z/RWDzhg/xXbsVaHJaT+1xO3LGO+X3EEF+V+vzKq4cXffW5nCzL9p2WaIzaW+sS 3cXTmLTfKSdZuorAW8twtjm2Gt/bYmUbqdq87U/vJ5qu/PoL+ekznN74LVXe1NPb/S3uHFyu Bl+973VyhdwCebkTLrkVLxCqy7l9RVnuy3mikY7Z3q1AnXwU73RgvXDGX3y/Yo1t/sO62eak TU/ueZqskPscd0ILlqw/cYshfqSaRa194rZ1+3LJhZaTk5OTW7Tp2LGACubkJx91Obf9lOXE Nw7e5jPXrhVKjlyXU+Gn/DWu9Rc/rFxzqeBRvfgDEhZCT0J1t+76dnp/i35YeexSAbN+lh+m IIQQaqNUE1w3f7HsK8kuD7gGplROP7pw6Qa1SNZzKkKoNDvK9JCcnHjGy5cvP3To0GefTf5g 0ebVqgGFbG4XQqg0LMp0x8Jlm9QkauQyEXocqrNlp9QZbTl7NqDwtfN9vcpQHR2pvharnLAn VEiE+wihDoRi7fetWTW50nJya/VvPQ7ysjDZLvfF4tVr7YsfN0guJdHeQmXlVLfL9e1uF03b O6u2vsxH64t5uF+Ri+Tk1NwKXwj3/OuoL4vV+mK18PCiLWtOBBZzeF3oxX0PbVXxv30U3a+n vn6LQPD+fBjhPr+q+b75Jnn5+cK6ct/t2qwbVYthouCorbg24Ii8vPxq8+Q04aOLgyys1ktv y7LvJCoOqljcKcY/VUrP8vVWXyqzruVUV2KV0Xcsdkk0+m7XFr2oWvE26/wqUrL5Jnn5r6d3 t1Rdzy9bqo7vrM6fSUr23Ci/dLLr79fu1U3BOiQeUJzAsMIoyyM7JcbVmPW4gtbxe9p71nwv 6mH+8nmbvVNa2AIM41elJpmtmur8+93bzkTXjo9XBim7BCd53JQ6umfbmWj8HvT9nbUv7Baf u9UUHeTtobYEP8kzV3Io06Yxmqy9axXuAn42T361hV9GjTBGGh8bLXDapbJKNMnPt/qktLAF 2IvCaDMVcceafldyuiYXpyXDS1tiWE2/S17XE01XTfXMr2xINN0o8wrKy3+/54z+bQo2MY6R b3lp71wimtTnqy0fZNQIeC/uJZqKT3/pXv2rt6VP6Q2o1BdXTsnLfytj2N2ql2KLZbxkHMMK IkyVd8jLz/95+zbfOhkp4YuISNMdMrr87HP51ZZXMmulnxulFlRcVpaX/0xefo3WlczcaY+V 9tPrKt03rvvxKxl9rlM76CFrmm8yhmH5wlOYZvGX889eJ9Fxz6eOYxg53V1TdQm+2R41+zj8 qLznSXeNV8q6evLLtK5ey3uXL1RgWF648aHJSc6Tl1+jdTU79HaYn7L8vC++WmNFzK5Ds+6V Rx4gaG35+Zup+c37Un6N1dXsOuEUR18N5NltUVohWo2vFugHk7toWEVumLGy+CV7LzrG12IY Nj4yRA7XUN82eft8/pX8seDkhOBEF9WV8v/6asGZYHJxsKu66k+4o08fVyS6nF8pP+/L+Wus M3Lq83LDjA/JL/hy/k7rjI56JHyQ36t8gGCxefkKeXHHC47faHkqviqjr7C8S0ZK4uMSvvh6 kURjbAzDmtNc1Y//JNFsvbqTl3QVgbfWkvPE5xC+twWr9krV5h0bHmgOO3lyq4z3lrAxTfC2 n3uKccvvxhrhbrP1GioOsQPlrmqrFn8rv1fDJeEhho0M9uVe3HhwhWikRXuuZtEE3VhF9g1D 8YyXaQdcL2TOPJ6El6/6y26qrdoieUL77FIT6qYa0VKdHI9JLrTwLvtq0Vqb7PxG0V+OkcG+ HJv1ij/LuHw/bj1qmIax8Z8ojgxiOTbnJFsv1wkMKcKfAq0szsFQxlvwc3n5tTqB+UWzPV0M E945KY6qR3+U7HKD5nG/RzKPKtinJdZjGMYZ6ImzXvuTeMZffvmlqqrqzz9P/uDzr+XXXrxe 2MTEMIzT0BOnsfanhQr2aZI1cjuextoZSt3jP2373ii9gzPrfztxnsbelupr4Zpv9/vnMtC0 rwCVZwSdU8KttKJpaGB68R0N+Z8Wyi8/HRwqtZTNGcUeB6eaL1Y8YE5okN77axjDsoP1FLZK zEBByyPpkXjUYD39LcLFmS+/1ja4iMTCOG3PopzWy3/3pby8vLz8Ru0Tlx9h4PftvYb7XAa9 ndI8VTqwtZ2O22iA3UlrJTeRKZRODl/4TCKPxaK3khsbm3DlBknN7V08vjiHE/B5nE4KhYxr Iq5rie9qsjVitrW2NEu0k5qG1CSnuiM1kjvobO6/UcWRy6K3t+K6Jrd2TtvAhMfn0dtIpOZ/ c1wOg9lBwRW7pFDaGRyEBAhxGe3tFBK+gGN7F4s6Ge4XVMo4in9MUxjua93hUSi4ZX/dJKWm 0djY2ERupnSy+AJhLsVjM+nURlKTaJLUDgYHCQSI2UltIYs6biZ3sCafrOTzecxOCgk3bDO5 g9VFa22nkKZ65nbJvoKiE6J3sXiIz+Ex2ykkYV3FxiYyldrJ4QsE3C7x6Tc1NpLb6Gzpus1v wmLQWltkjClZQFjycvO49DZSE6mxkURpl7EZPZ+HmG3UFpKMXknkZurUSuJmQaO1khsbSaRm ageLP/2ZVB6L3tn6muWh0DpnvZ/61ClMQ6a00iXrVPP5PGZnC6l56v0qo/wst6utjSKjvyZS M7mDPdvHbGVNkkRqpnaw+V0d1FZyI4lMpdI5fMHsntxHCCEOg9EhecFJ5GYqnT11ezPo1EbR TdZIprTRmYgvQAwalUwWnVJzY2sXi8NDCPE5TGZ7c9Nk68ZmCrm9i8+mtbU0kxrJlDZaF49J a2kSLV0zhdzO4As4XW0tFJLwFNh8gbBnEpnaQefQBAJhuJ/2jNFBxf0Wbaa0tTPR1Ony2Fw6 ldQk41eojMaIz+cyO8XTmLpxWO++ET+L1kElS6zitNq8k4sjY4azL+Qrwu1qa8O/syg0Op3O 7GxtbiQ1NrbS2BwuQlz8FSRRqR0MjvAKUsi4X1BszqzvSR6H2dnejP/T1khqJrd2CTiTv3AE fC6H1tLSLOOcSWQqlc4VTF4VLpvROXWbSWhpo0vXr+ayueKKsqJTIJM72Bye+BQECHG62lpk /dYhkcjUDraA9y5lQ/g8Lu4Gxi87kzv9qHA1uHyEEIfFaJe4gZubqVTcKZBayK10tkDARwhx uhjtLbjXvvGMWtraZFX3npH0ndPY2EiittKYXOlwn49wt4rob0oXh97Z0d7S2EQik2n4ZUcI TXsvNLfRpMsrI4S4PE5naxP+V67wjuVyRQvNYbQ2kUlSi8NldrZN/eKndNJn3OUJvA8fRrg/ Njwy0M3BlQ7kCPqHMWxceHR0aLiPx2Aw2GhgUPgY5sQYNtwr4LCYEhUHed39Q/j/1x0d7O3l s2TWtZzqSmy4vx83Bfw0JqYmiTgyu2PxBb2Dsy28hz//sZGBXg5DPFcmmysYwEbH8W0mMGyo v5vH+TfHHR+dGBBw2eKVYzE4vYMjY+MYNjY8OIDY0qc/Pt4YpOwSnBTyWNZR8eLgwv3sesll Z/EFfUPSkxwfnRgQcNiSF5Dd3Tt5VSYmJoZ6ODy21CSHh/oRb6rj3r6hscnFGRnsFUgO29vT 2yeas7DnN1xBBoPJFQj6R7GJCWzkZa+AI+6J3T04ODw+NjyAO30WV9A3i11GsNHR4T4Bg8GU MSyX39Mva6eMCQwbeol4HAaDweJwemXVIx1+2f+6s2F390nf31PvIwaDze8bHJr2QPP46Mhw L5st8x3D5nN7ZW7o8Qa4U5i22AyGoG8EX6daeAX5ku9X6cWRvAoSWPy+vumn9C6TZPP7Bl/2 v+zlTV79kfGZu5EyNjI+wJf+/cTu7hscmby9xyVub6bg5cjYKDY89HLq9mZwu3sGhjEMm5iY GHnJ53NwvfFeDgy8HOjhs0WvHXrZg1s63suBV6+GB3om7/3BoZGhoZeIx2AyGJzuwdGRcWG4 H1o1PsDmsPDvat7LkVfiqzIxgQ31IJ7sBZduLLyCPXye5P3D5vf0zjpdnzQy9KqXJzHktNq8 ExPj0ovz+sZve/VeDfTjbzM2n9fTP/6qh89mMidLIk9MjA91s4XlVxlMNpPbNzg6No4ND+Ku IEvQ93LW9+T4xPirl3y21AlJlWMdHezp4cl8ozLZ3YNDk3esxCQlsTg8NIiN4W/tiQlsqBtJ tp52CqOv+nte8xZkC/qG3uUt+Jo7h8Hm83pfyTw6uRpj4+P93WwW/nV8Pp+F/wG7u29oZAzD sLGR8X4+m8WUWknZZ8TiMNHg6Nis3/hjr/r7pfpispncvqGx8Wl9vRrsw73ZGSwuetk3ONTP Z7CYDJbgpfSdMzI4hH8vMLnc7oER3N/fyZUceingSv7K5fJ7p4p4v3opEIgPs7tfDo2MYWOj w/097Mk/T2wBv++d37HgN+K977kP5qL2yXC/pGmGlsJw/1Qsap9WnhAAMGdIbcEPAABgrvsw wn0wVwn33HcJTgp9NkNLcbifN4tH2gEA/3lSW/ADAAAAIhDuAymtVXl3Qy3U1Dd//dNBc11j W9vL0ZHSdV8RQjyEmkvvXvfW2XVo+8rlR20trG1tr6dKVN8FAMwF7XXU3EBnxyOblmzbe0DT 0NbJ1Svsfu204rQAAADmEgj3wbsa6GXXFgS72B5avENR9aC+q6tvkFtiPQtN31a5h15XkOxm dG7rJ6uVjU+ZuboGxkpU3wUAzAXjoxg5KyXKUl3lwLplhwxd3RxdAwmlzS29M78UAADA7wGE +0BK08M4b0e1vVN0nexwFXQncRGqTvU2NjmCa2kcfEvGxwAAgPeK/LTxzgXlg/sn36jKR9St g8QVdAEAAMxJEO6Dd9XDayu8ra+ocVhR5MQZJY+SVhmVgznNJbev6SpOOW1vEVkpo0sAwHs0 NoI9C71irT35Rj2oqHjaLaG8AipoAgAAwDAMwn0AAAAAAADmGgj3AQAAAAAAADOCcB8AAAAA AIC5BcJ9AAAAAAAAwIwg3AcAAAAAAGBugXAfAAAAAAAAMCMI9wEAAAAAAJhbINwHAAAAAAAA zAjCfQAAAAAAAOYWCPcBAAAAAAAAM4JwHwAAAAAAgLkFwn0AAAAAAADAjCDcBwAAAAAAYG6B cB8AAAAAAAAwIwj3AQAAAAAAmFsg3AcAAAAAAADMCMJ9AAAAAAAA5hYI9wEAAAAAAAAzgnAf AAAAAACAuQXCfQAAAAAAAMCMINwHAAAAAABgboFwHwAAAAAAADAjCPcBAAAAAACYWyDcBwAA AAAAAMwIwn0AAAAAAADmFgj3AQAAAAAAADN63+F+Z3V1XrSPra2dra3n7byC6k5aY0VBuK2z g62trWcwoeBR61Rb8hPi/SBbHFffkIRsMmLzpvdb8yQ9Ctc2KDo68n5Ookd8OZ3JnTzq5OQe klzVVZQSEXUZ1zTl+VPytP5ojbSCMHdnh8lWHq6edwvpzM7J4xwGrTze3d/d1jUkISHrCa6x q9+NRJmTbC0lEIJdxeN63k6JiiQ8uJOYTUZsvnjcBlpBmNvUuLZ2Tu6+96pqqax/e+kBAAAA AMAc9cGE+yN9GLMwKeSqr6urb1hiYgUPwzBKXnhMoKurq+/VkMRCJtY7Imo7iJh1Ca6Bvq6T PF1dg9NqOV0D0/sVCBilCa6uk20DAwMT6uoSAtMqXlAFuKMB8UUNTypflN4W9+kaGEPMo8ia KiWXGBM41c41Jv0FtQt3vOs5Me2mq+fVkOBCJrcqY7Kxp6tbSFodd/okB7rqa9MCxN35ht25 lfm0MCSksInLEDeemMAouekxAbhxXa/eLSpu7vm3lh0AAAAAAAAMw95/uN9aWhrnpLV7x/6f v1im5WB+hZDg72l5bKOiwp69m7ceNvLxzqQKG3Y1PEq+Zm2gsnkvzmH1M2b+KZmVrHamuEce QqTnBUG+Zqem2m5W0T6y58jpo59p3CG1MRF6TAyz11u3edW3q3SvxVme1zx1aNvevXv37t2z d+9GFQMv5/CighdUcY9MSnXVgxsRFsd2KSrsFHa4U1Fxt47lrcS0aiqFhRBCLBolx0v17O5v 1+w+dlDPearxho3792ucCiwt7+KI58jnsGgvsm+7nT2rijsZLV3FbfvUlfScHyM6RzQwpTg+ zuLYrgOT4+7du/eA0l49l8txRc+baP+RKwQAAAAAAP7TPphw/xUfo8R4Gmipblqy5ZDqPs+M 50Siv+kxnSN7FPfsVVbR1iV0tQmGMQwb7ma0FMc7a25WVVZQnHJQ3y0qvrSjHeE7RdyOgowI a83NiqK2e46oKhx3tlo/74R/WC4FwxjMlgR3RcUdC5cdN3Wz8r1sfXLbZIc7j+gYm/oXEp93 9fQPC7sbHeztIRUVB5gZ6xzZKR5520kjj9DYF83tL0WjNmdcDzi9dvfGlT/oRoReMhA13rtX ccXqo473k+u43bgpDrKan90LcNM/OHUqJzUPaZ5R/XKxZVLDc55o4InupuchVmbauHEVFQ/q WNtcTy9t5Pz6lwcAAAAAAPzGve9wX4jRiu5oaNnortu8fd9Kxf2+ZVQ6F9VEBflfM/XORQI+ 4tJLg85csL5kGl2De1lZyT2bk4t+UPaqyq/jTj4Zz0Aoxn7vfh29K+HitjVRgef3L/lp+xLD RHKHKGNvKEgNUFx0UHHpRtPQ61nCZ/U5CJVFmezfs+Oosn0ynYv4AoS4jKpETxf13d8d8E2n 0kWBOu05OdVKYdEqDbf7ydVsrnhG6Xaemhu++GHHInHjsjsJFse+mn/St6GtYfJ5fHYH6ZHj 2g1qdnbRT8UvzfY4prHu+7UHzX3LURcXIcRlVyUn+V3YdsA3q61LHOQzWpsS9BdvOmJqH/mQ OTUwAAAAAAD47fhgwn2xZ6GEa1pLNHWO/lN+u1lyWhUf41c15/tv0rlPakPY2FDXk7txl1Q2 edWSmOLH2rsx7L7L3pVq58JuPB4aneqrPDfM6uSPx51qMdHz8vwqUrL5Jnn5+SrX7hS3idtl WR4yObxk11lLvaiWyZ/Rq9K8Tbet/NvhsKdk3sg4ho2P9LZVFFouW73H2jOtaupR/ZYoX20V FTWnqxUDIxg2Ifphdp2fwjff/PjPtVYewsaobfyeztYfDuuHZZeNTU2xI8XR3khjrU2e+Cet RTHXVOZ/Nm+z+f3magGGYeNjve29BTZqx9yvp1fjvyJQGWVpqqG03fpB3wg2NvFvrjsAAAAA APhdm0Ph/v41a9ZruPjnUyidHD5fgLgMOp3e3slGnE5U5nvewtfrZn47A59nc9jM+rpygq22 W1Lxi8mtdIThvraFTcQDcVsug95OaW5uaW5n8vgC4c8aCu76Kv7jU0XXiIwqOkv40YAAIQ6j nZIZ6OplZuhXjuhchGqir9lYqen4p1M66Xy+KJ/nc3mdDZQ061OqtpeCsqc+cEi3s1FSWLLb JpjS2SFszGFUpcf5qGy5mE15PpnQC8P9Q2bXfFIbxS9ldVJbySQypb2Tg/gChFB15jUf93MO oZROmnhchAR8HrONVOBvGxwWE4P/pAMAAAAAAPxWfIjhfrjBrs+XHrHOYdQyBgaHx7Cx4ZGh Po5gYGR0HKNnp0b7q1smc3qHR8bGJ18zjmEDPdzH8QHh4eHZuK10ynPDXHVWmt8exnjCtmPD IwOIw2AweH39uE8BsixX7z2spRtQLOif3PoHGx0e7G179jD48CrfHFK1AMME1U1p7uuWW0Q/ bm4fHJ568Uh/b11cpIfdYZ3oOgwbFP6wJfuFh/L4e/WVAAANJElEQVR//ZeibUFtrbDx+OhE Py/RUMU7Iikdl9B3pDh62xooB9aLfzI61N/HYzAYnO6BkeFxDMP4zKYc7w3Hg5/W1ePHxbDh /m5qwb0UHzufOow1+G+uOwAAAAAA+F2bQ+G+2ll789Ci+q5pR5lt6N7ZQzs2/mv5JgVpu3fv 2vj9F5uMQnMLRLvz8xBqeh7n5ap/At/utNOt6CcSvTYUxPuryG9xKMmqZEoNWJPgHXpJ99x9 1M5CKM/d29lZy7uQhhAf34jPRLQUD3VTF7/YfPEP0+1crS4ccc4gISTeY78+PyXkxEbrDEpF x+RLOSza86zgi5qnlHdMTVHd5XLCI9LUAHkxdpoHvv5+hYLC3mmnvXXpdxtVL1xIwDUHAAAA AAC/FR9iuB/nabLtQkpTNzY4Ou1oTWSUleJni9YpybBjzdJtKvpXEuni1ohTl/HAVR/fSO2M hWcJxuyT6DXLcoXeBR/vXCQ1Wh+tvsTkB/PYhqJ2DGsvqr9t+oMOsbyj55VUu4HaoqgAiyOO aRgm2nKnJbsmWPeLY3cLWgXiCzAxPp5lqXI5IuEBDfdSJulhvK/VyR24KZobeWdSMWxylPa2 yiDNv3y2cfuundPOed+W9Vs3bd8RTCVzpCcFAAAAAADA25tD4b624y3fB02yj8ao792nuFFJ x1oGG2trz8jc6upO3EtaH+bGBbpOtTljaHT+vG1IcDa5a7KybUNBfODRz48EkQobpQdsSvWO cNLVjEVtTITS7b09PXVDK6dNi43Qo5BTxl5+kUTxz9LtpjeeHu4LVRNvRnjjzuPMWaPzTi6R Wc8Q4iKEUHqE9SnFb7cctra2kHXaTkF3CaWtCAAAAAAA/OZ8iOF+wnVXletNso+Wh4RZHv5s /UlH2Xxv3C18xsW17+9i16QEOjq6ihpcsLU1OqPv6pdc24CrbJtlucLCPSykXHq0fnp9pd0P BrcacikYRsmtv2X4g11lA2N63d6OckK425EL8RgmEP6gJXt6Y5nhPoZh/JaKkkjcSVy4cMno goFbYiETCTAMw1oozy8f/mjx4TPGxrLO2dUvKCifwRGXGwYAAAAAAGD2PoRwn92OcsxU1S9Z B+ZQZRx+G00Po2wuHDuwzjC1qoMlrFbbUBAfcOSzfd7P82o5Uq1rEr1DL+meuzfzk/ue057c f/twX9rjW1f0TiiomPqTUBcPIfSY4GJpPPWfAAAAAADg9+K3Fu43x93xtdmmfacLw4bfpfce fmtWjNq327RDb5fQxDvZZFmuMLIP8H8ovbVNH63+odST+7oZ5R090kMP1gmf3H+Ae3L/7cN9 aYzKxkirFfM22BU01/ZjGMboqIkznLfBU/SfAAAAAAAA/PI+hHAfMRFK9Dp8xvJCMKGNzkRI ID7C5/JZNCqZ0tHFFj6RL+DzuXRqeydD/IS+ELcmMcnPePU2zwyKqChuQ8Hdq4c+XX4uMq6I hG/MZXTkh3r6Wp73Fe25H+VvY6WmF5hN57L54pF5fGZzB9FG+7itbWAWfs/9twj3eXweo4Pc TmdxJArichmFIZYOusp6SaiDhRBCZXccvAyVNEJa6tr4nKkJChDiMDqobW0dHdIVdfl8HotO Jbc0k0iU9jY6+7ULDgAAAAAA5rDfWriPVRZH+xhtMA1hoc6RUYlte0YH+pBAgPoGJn86NtTX 39eDBiRajffRBh+aqhx0vHqvUrx/T5bl6pNnLKzi6/GNx0cGmXVPw46u9cslVfExjF/V9MBt 7TLL2BftXSPjuC5fDTTeve1hp6wdVYvbc/8twv0JDHs10NPb2zMgsaXO+DC3qfTm/j+eCasq bMcwDENtVfd0Pj59ueBBzcCAxAcLY8ODfT18LrdvZFSiou4Eho0O9SEBh8Vic1locGQUP2EA AAAAAACkfRDhvgAhZifB1kbl6OaTPkkITe2RT3tBSb+4f/E2w4CcbDJCCHE6KWW++3WdwoOz yfguymLs7TW3rb9Y0ERjCx/AbyhIvbrv6+XLPlmpfw3fuCba1NbGSv96qaiwLZdRleDpa66u 4FdOpYvDdFJrU4jhD+vOut1LqmZNRexvFe43tTaFGy457f/gUTm+XXXU1TM6hw7a3mIipgAh hDiM/MxI/YPzl6uHUB41i9txECqLMt6voWlmIV1Rt4PWkuaj8P2ahZ99tlFb3TfvtQsOAAAA AADmsN9cuD881EAsdTj693m6/jXtbfgjlGg/PXV1Pb/oyYq69Gy/G962Z6Ip+FaorTJF8y87 TaLjn7LEQX6W5aGTmz9ffkQH31hQnZbmrrrKuuBFR+/wGIaNDfe2VRRYLFdxT0+tFuC6LLxt qWug5nT1Wf8whoki9rcN9wtvW7u42MQU4afIr2pMtFv9x/3eZZTmUQzDsPFRTj/vuvmmFerm 8TFV+Kb0qgfetge3bfWpI0tU1J3AsJYsH131ZfPm/WvDF3opdR3dr1lPAAAAAAAAMOy9h/s1 mRFBxgoKe3YprPjiq++X/2vNVIFZk+sFmfjsmvr82b1AH0styXq6B5X2aFtEJKRWUShMhBDi 0MiPHNdu37jqR1xXCgoKCifOnfO4nfWCxuaKNtdpKHhw/chKHd8wk3Pq+MK2W48Y2AQkP8IV 9mW2VBXHX7E4vung/n3iZorKR/Wc7yY/oQrHZdEoud5q5/Z896/Fi79ao3rCPKakg9GFHmeE OZ5Zv2bp5x9/s3anssPdhEetCNVT6y+ry32zbtVGiQLBW49om/tdL3iOK8ZLayPlp0c4mSgr qUy126ugsOmIgZdH9KNHDVLVh9s7SEkOa/6+4E8fffS98gHHjF/tugEAAAAAgF/RhxLu97Go JZ5KZ9SUlLYsW7X0h8+WThWY1bMPjnyBa9rP6a7LTvM30VU/JllP9+R59xsxFaS2yWK5HSmO Lmo/z8N1paSkpHRMXcnE/+5Daheaelw+y1LF3sHO2NUdX9h231FdNeuQwqbuvqExYbPRwd7u psJgqxO6R/fhu9SxCgjNmhqXnBkcqLd++/IFf/5u63YN/9hHLVyMwWxJ9FBS2rnosx+Xr9p+ zts7k45hExiWFXL28K75yyQKBO87euK4pXNaRXW3+OINT0x0NpREB1qd05E4md1HdU3MAwrx k8QwDMMmMKzpvv1hBfmPPvr7ov+jEl9JxX8aAQAAAAAAgLT3HO43P05LviarXKy19bV7FY+b JVt3VlXlRHpaW9tMtXJxdI0t6GTSJpvwWPTmjMBAL7vp5WfvSpafbSh4IHygPjk+TKKw7bV7 6U/IkgMjWsOzvFBrB1txIzt756DEyi4KS9SA09VRdsflsovwoJdzUGZlF5uFqh89iBCfn1tU Xn51J0IdXR15d1wcXKTPOOBW+hOpR/ERYrI6n2cEOHpKnlDAvefT5ijZ2CcyPHNaZwAAAAAA 4EPwoYT7gwJG7V1Hf08ZBWOvRqVlt0i2HunFGPmEID/J5pGpzyl0XKvupsKCO77Ty88G5jPY vRK72wgfqL9V+FyisO3VqNAcqYExDMNasm9EXZWY4J2C+ibck/H0Z2mpIeKDqQX1Xd0Yn99V Eu/oKJyw5w0C4RlX+Hz9s7SoEEcp/v6hOVM7/IhMYBi3seCu1An5R6fLmiOusdc1p7u1DIF0 OQEAAAAAAADw5sa2PO+DONx/9uY6twAAAAAAAPxnfSjh/vslDPdTOt73PAAAAAAAAHhPfp/h PpvZ2fYkKdpbebVR7NOs5yRya0cHgzvz6wAAAAAAAPj1Qbj/RqOjIy8Ri3X33H6nK2FRz1ks zvTitAAAAAAAAPz2/T7D/ZxYV83d//z4b3/4nz//Q+4Tuc8WHzQzuw2b2AAAAAAAgDkBwv03 amuvCdCdN2/Bn//wv3/7+GO5eQt/3rbZW6o4LQAAAAAAAL99v89wn9rwrCAzfkpy9iN8BV0A AAAAAADeIwj336i/v5v8LC0tK02EmDO9OC0AAAAAAAC/fb/PcB8AAAAAAIC5C8J9AAAAAAAA wIwg3AcAAAAAAGBugXAfAAAAAAAAMCMI9wEAAAAAAJhbINwHAAAAAAAAzAjCfQAAAAAAAOYW CPcBAAAAAAAAM4JwHwAAAAAAgLkFwn0AAAAAAADAjCDcBwAAAAAAYG6BcB8AAAAAAAAwIwj3 AQAAAAAAmFsg3AcAAAAAAADMCMJ9AAAAAAAA5hYI9wEAAAAAAAAzgnAfAAAAAACAuQXCfQAA AAAAAMCMINwHAAAAAABgboFwHwAAAAAAADAjCPcBAAAAAACYWyDcBwAAAAAAAMwIwn0AAAAA AADmFgj3AQAAAAAAADOCcB8AAAAAAIC5BcJ9AAAAAAAAwIwg3AcAAAAAAGBugXAfAAAAAAAA MCMI9wEAAAAAAJhbINwHAAAAAAAAzAjCfQAAAAAAAOYWCPcBAAAAAAAAM4JwHwAAAAAAgLkF wn0AAAAAAADAjCDcBwAAAAAAYG6BcB8AAAAAAAAwo4/e9wQAAAAAAAAAAAAAAAAAADA7/x9G nySnYX7H5wAAAABJRU5ErkJggg== --------------EA422DC7FAB5A2E96AB6EB8B-- --------------D8BF43D19305363030A1D58D-- From nobody Mon Jul 11 10:06:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8435212D5DB for ; Mon, 11 Jul 2016 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z99_IU_ekmkr for ; Mon, 11 Jul 2016 10:06:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BA612D58C for ; Mon, 11 Jul 2016 10:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4203; q=dns/txt; s=iport; t=1468256796; x=1469466396; h=from:to:subject:date:message-id:mime-version; bh=7mh6AtGq6nLC8H/DPVhc3ysckqVkjobLG5cDpxsSnNY=; b=jln+RX2RiLy7h5xCfN1us3HWDhgpBTWgDYIBTjLiPZgmU03ls8dyiOvy MxgECvALaXvVWKF82Gg8ReS8jBKLXhCjLSe9jFNnCynPP79k16nOQ1FQ+ intJOUpRqFVq6MFgQaeJ3E6LoAqwR+lfq5tIU+2q4K/rq4BApIj0/5n3H U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAgCz0INX/4cNJK1cgnBOVoECs3SFB?= =?us-ascii?q?IF6h0Q4FAEBAQEBAQFlHAuEYy1eAQx0JgEEG4gooGSeOwEBAQEGAQEBAQEihie?= =?us-ascii?q?FHhODR4VxBZkYAYEyjRiPM5AOAR42g3GJLn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,347,1464652800"; d="scan'208,217";a="124709343" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 17:06:34 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6BH6Xad014665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jul 2016 17:06:34 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 11 Jul 2016 12:06:33 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Mon, 11 Jul 2016 12:06:33 -0500 From: "Steve Truong (struong)" To: "netconf@ietf.org" Thread-Topic: Comments on draft-ietf-netconf-restconf-15 -- 3.4.1.1. Timestamp Thread-Index: AdHblpEj02slM+NjQ9e2/WOE0qliMQ== Date: Mon, 11 Jul 2016 17:06:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.110.168] Content-Type: multipart/alternative; boundary="_000_eb00aa04ed7b4e2792454e863c555a8bXCHRCD014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Comments on draft-ietf-netconf-restconf-15 -- 3.4.1.1. Timestamp X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:06:37 -0000 --_000_eb00aa04ed7b4e2792454e863c555a8bXCHRCD014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the RESTCONF server is colocated with a NETCONF server, then the last-modified timestamp MUST represent the "running" datastore. If the "running" datastore can also be accessed and changed by other server= s such as CLI, SNMP, ... how would the timestamp be reported? This question also applied to the Entity Tag in the next subsection. Another question is since restconf is supposed to be a (simplified) version= of netconf (providing "a subset of Netconf functionality") how would netco= nf provide the equivalent capability to its clients? Thanks, steve --_000_eb00aa04ed7b4e2792454e863c555a8bXCHRCD014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

   If the RESTCONF= server is colocated with a NETCONF server, then the

   last-modified t= imestamp MUST represent the "running" datastore.

 

If the “running” datastore can also be a= ccessed and changed by other servers such as CLI, SNMP, … how would t= he timestamp be reported?

 

This question also applied to the Entity Tag in the = next subsection.

 

Another question is since restconf is supposed to be= a (simplified) version of netconf (providing “a subset of Netconf fu= nctionality”) how would netconf provide the equivalent capability to = its clients?

 

Thanks,

steve

--_000_eb00aa04ed7b4e2792454e863c555a8bXCHRCD014ciscocom_-- From nobody Mon Jul 11 13:48:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077F12D50E for ; Mon, 11 Jul 2016 13:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoq4oa_cs1M0 for ; Mon, 11 Jul 2016 13:48:01 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E4D12D0FA for ; Mon, 11 Jul 2016 13:48:00 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id t190so39491562pfb.3 for ; Mon, 11 Jul 2016 13:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=+d5viXsFw/16qTgoQLe7smei3/JtRZ/PiQhmD/RhYco=; b=PXsN3glvjA01Jt0s+0yUFV6KPNhRv+j3LUNgxPqXYi6PoIMhTikEiH3YfkcxU4dyWh nIOxnkQhvaNDtmkAAGWDTMAYHk+3kl6JFtHgIIPaKtBAR+G66eh/F0m3VWghKRiHmLGV CmcbB0yqTarrJaMdbvo2besJWt9nrT78c+QYzDz+8EWJoO9eGy7Ew56M+OUdOFkYd+A2 FcqdKbmzX5NdzAxUZj+e6vZ/YTTgrmUmP6a7Df4y1Yf8+YYuDBOP3oMNtpZrt+jx5EQw aijCGWHy0M7TDU7O2L7HpfgF2XGlDR7HcejpP7vR7wuEvh6IRHX8gRFBhbeSi8d1q9pn 9FOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=+d5viXsFw/16qTgoQLe7smei3/JtRZ/PiQhmD/RhYco=; b=d4+z0KR3qndyANGwq4kyIgEe1YaAGOQDVddMfxT83xYNP/fGjdpaW+8GYb8LPm3dU7 ORLUHGngAl06tXC8zW8XMqfGLLcuesiI2x4VdFz+cwEgqbL89uxJy19lFGbrUjh7FZ3h +nWcX0h6w6P1QmuBeh/XKRvHgq46NRmfj3SMizYajU3B4nb/LgLSgqAWPx3Tn5inL4fZ QvQpZw2IuU+jiq2mQJ455ZXy1HUfFKsY4cZz1fxpuO+qBN1RTT80EeWUvkfK/AsEHDiS Xjww5DrzRDEPwHo7o6dzJzv5QA+7AAX/6BaOKr0q4zZ7tqzH38zEU2Vr5HfyiUoOKAq7 gKcA== X-Gm-Message-State: ALyK8tLbumUeXjFHaIkzwTPAsRy5Dls1mpO+gcN/vM8REd8E51+zxznXhxcZ51fv77cjgw== X-Received: by 10.98.79.194 with SMTP id f63mr38185457pfj.95.1468270080167; Mon, 11 Jul 2016 13:48:00 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:c58d:7bd6:a7b:c2b7? ([2001:420:30d:1320:c58d:7bd6:a7b:c2b7]) by smtp.gmail.com with ESMTPSA id uj5sm6956383pac.28.2016.07.11.13.47.59 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jul 2016 13:47:59 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_72FCF3B0-817B-4EE1-B9C4-6AF935706C02" Message-Id: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> Date: Mon, 11 Jul 2016 13:47:58 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] What should a server response be? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 20:48:03 -0000 --Apple-Mail=_72FCF3B0-817B-4EE1-B9C4-6AF935706C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Opendaylight controller is constructing this particular set of = requests as part of a single transaction. The response of = the server is to reject the configuration that the particular node (evpn = container) does not exist.=20 However, if the default-operation=3Dnone is removed or changed to = replace, the server responds with an RPC OK. Is the server right in its interpretation of what RFC 6241 says? In = particular, the way the server is interpreting this request is as = follows from Section 7.2 of the RFC: none: The target datastore is unaffected by the configuration in the parameter, unless and until the incoming configuration data uses the "operation" attribute to request a different operation. If the configuration in the parameter contains data for which there is not a corresponding level in the target datastore, an is returned with an value of data-missing. Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted. and then this: operation: Elements in the subtree MAY contain an "operation" attribute, which belongs to the NETCONF namespace defined in Section 3.1 = . The attribute = identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the subtree. 1st request: =20 rollback-on-error "> ## =20 The container evpn in this case is a non-presence container and does not = contain any mandatory leafs or default statements. The server therefore = interprets that nothing has to be done here, as it is not required to = create a empty container. =20 2nd request: =20 none rollback-on-error "> ## In the second request, the default-operation=3Dnone again seems to imply = that nothing needs to be done for creation of the evpn node. Therefore = by the time the evpn-load-balancing request rolls around, the request is = rejected as the parent container does not exist. As stated earlier, if = the default-operation is removed (causing a default of merge) or = replaced with a replace, the transaction succeeds. A second interpretation to this transaction is that the server should = have created the evpn node as part of the first request, and that the = none operation was implying that the node had already been created. Which interpretation is correct, and what sections of the RFC can one = cite to support the argument? Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_72FCF3B0-817B-4EE1-B9C4-6AF935706C02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The Opendaylight controller is constructing = this particular set of <edit-config> requests as part of a single = transaction. The response of the server is to reject the configuration = that the particular node (evpn container) does not = exist. 

However, if the default-operation=3Dnone is removed or = changed to replace, the server responds with an RPC OK.

Is the server right in = its interpretation of what RFC 6241 says? In particular, the way the = server is interpreting this request is as follows from Section 7.2 of = the RFC:

         none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the =
incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the =
<config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an =
<rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and = then this:

      operation:  Elements in the =
<config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The =
attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


1st request:
 
<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" = message-id=3D"m-23">
  <edit-config>
    <target>
      <candidate/>
    </target>
    = <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
        = <evpn-tables/>
      = </evpn>
    = </config>
  </edit-config>
</rpc>
##
 
The container evpn in this case is a non-presence container = and does not contain any mandatory leafs or default statements. The = server therefore interprets that nothing has to be done here, as it is = not required to create a empty container.
 
2nd request:
 
<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" = message-id=3D"m-24">
  <edit-config>
    <target>
      <candidate/>
    </target>
    = <default-operation>none</default-operation>
    = <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
        = <evpn-tables>
          = <evpn-load-balancing = xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1.0" = a:operation=3D"replace">
          &= nbsp; <enable/>
          &= nbsp; <evpn-flow-label/>
          = </evpn-load-balancing>
        = </evpn-tables>
      = </evpn>
    = </config>
  </edit-config>
</rpc>
##

In the second request, the default-operation=3Dnone again = seems to imply that nothing needs to be done for creation of the evpn = node. Therefore by the time the evpn-load-balancing request rolls = around, the request is rejected as the parent container does not exist. = As stated earlier, if the default-operation is removed (causing a = default of merge) or replaced with a replace, the transaction = succeeds.

A = second interpretation to this transaction is that the server should have = created the evpn node as part of the first request, and that the none = operation was implying that the node had already been created.

Which interpretation is = correct, and what sections of the RFC can one cite to support the = argument?

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_72FCF3B0-817B-4EE1-B9C4-6AF935706C02-- From nobody Mon Jul 11 14:58:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D2B12D0B7 for ; Mon, 11 Jul 2016 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xCQGgzTIVde for ; Mon, 11 Jul 2016 14:58:22 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A81E12B03B for ; Mon, 11 Jul 2016 14:58:22 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id x130so31073960vkc.0 for ; Mon, 11 Jul 2016 14:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BVvM4K8vw2T5HmtJ9hA5bNZZ/Pft6hKyCV04FbasPdY=; b=HwptI6gCl21Mxxa6jhnOsoqFwzfD578nS/O70a90n9wUTYzX5VJLeTFQ0p7rwqB0w6 4+dIkUpW0Z1bd51ikOTdHIv6lOGTHM4ZCB9ibVSAZcQTgpw7bNDPvuVviVuZ4L0AZZS1 v8YdtKHs+hpk3XmvWSZvR26Tmhcal8IKOuX7a+zBXthTjzsq8ul50jXj2SOZTtlM+WDt rXD9kpQhuCd1eIhtBdrVxTrQOFYwYcevTh96DbHOiRldJfc+9l7OZthZkRiL8p0V4eY7 YYThEeK+q5q2X5HlClZct5PzqvO1rnkusYyUL7c35GN4SnXvXS6hyGL0UHPKru/LZCH/ 9zcA== 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; bh=BVvM4K8vw2T5HmtJ9hA5bNZZ/Pft6hKyCV04FbasPdY=; b=Cp+TUcCj1VxSK/XXWdZqjlrB7uCtGhW230i+JjqEOz1QVPklJZL8TA5+uTJjFBug5j hjJCOp+qsNukm7e46sY/sKAq7OYf1VQjPDnoZjbZEbWSfG/xrkJdxQ8zWJStxrerr7f7 czqT6wmpvwh1Jce7DR/Nb64JmauKHcHSK0B37L+DRt2eAQYEd09GDTN4p1etLlacHzGv uklLCdGJXBxS9Y/sfHlhFSrRB6Sl7i92xpEleNHfDIDug45uRL8BVLC29vOVkSHktUTW +mzVO16jKDPkvEWMONFQhGxmHOF1S3K0ajQBDgwia68q9ozya62oy+2HTIvYid2C2ceE Ycfg== X-Gm-Message-State: ALyK8tLom1FD7uGFlxyR0E0LMxpiZktH4a1aXu4wGCHR1c+FDDXZq/JpC7jiHnZCj8Sc8S606DA3hlw9GK8bvw== X-Received: by 10.31.9.65 with SMTP id 62mr10376184vkj.89.1468274301546; Mon, 11 Jul 2016 14:58:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Mon, 11 Jul 2016 14:58:21 -0700 (PDT) From: Andy Bierman Date: Mon, 11 Jul 2016 14:58:21 -0700 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary=001a11440b642d99e005376340b0 Archived-At: Subject: [Netconf] which error-tag? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:58:24 -0000 --001a11440b642d99e005376340b0 Content-Type: text/plain; charset=UTF-8 Hi, Which error-tag should be returned if an element is present but it is disabled because if-feature=false? E.g., using :writable-running; :candidate is not advertised I think this is unknown-object, not invalid-value, since the "if-feature" statements were added to the ietf-netconf.yang module I don't think the RFC says either way. Andy --001a11440b642d99e005376340b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Which error-tag should be returned = if an element is present
but it is disabled because if-feature=3D= false?

E.g., using :writable-running; :candidate i= s not advertised

=C2=A0 <rpc>
=C2= =A0 =C2=A0 =C2=A0<lock>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tar= get><candidate/></target>
=C2=A0 =C2=A0 =C2=A0<= /lock>
=C2=A0 </rpc>


=
I think this is unknown-object, not invalid-value, since the "if-= feature"
statements were added to the ietf-netconf.yang modu= le
I don't think the RFC says either way.


Andy

--001a11440b642d99e005376340b0-- From nobody Tue Jul 12 00:50:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ECA12D743; Tue, 12 Jul 2016 00:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vR2B9iI3GHf; Tue, 12 Jul 2016 00:50:48 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C63212B062; Tue, 12 Jul 2016 00:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=352099; q=dns/txt; s=iport; t=1468309847; x=1469519447; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=J0jDrEtp0Fa2AtJIAfdefRe/8998q7DtVOSuwgo/J0c=; b=ckS+MQv112VhVVlPIeB/Ch9G3QjYye/TsZOVUSYtqDnT/CvAACzWUBbZ nnN8t6WSoRJZEjfNaq1AE4NWSATa4b4upTSHIU5rTQiAg0wSPJii7+MvW MOSqFPjwZfjHxkeZS9hFxe7U61a4lGdlP4WC0kMbX0/7R2PD+/mZ3UWyo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfBACcnIRX/xbLJq3JBAICAYED X-IronPort-AV: E=Sophos;i="5.28,350,1464652800"; d="scan'208,217,150";a="638504438" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2016 07:50:45 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6C7ohul019786; Tue, 12 Jul 2016 07:50:43 GMT To: "draft-ietf-netconf-yang-patch@ietf.org" References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> From: Benoit Claise Message-ID: <64c4d796-1125-57f1-80e3-8a70b3ba6608@cisco.com> Date: Tue, 12 Jul 2016 09:50:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> Content-Type: multipart/alternative; boundary="------------1F7217D1FDC8B5BF17F110C2" Archived-At: Cc: NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 07:50:52 -0000 This is a multi-part message in MIME format. --------------1F7217D1FDC8B5BF17F110C2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit One more point. The trees in section 2.2 and 2.3 are not correct. pyang -f tree --tree-print-groupings ietf-yang-patch@2016-07-07.yang module: ietf-yang-patch groupings: yang-patch +---- yang-patch +---- patch-id? string +---- comment? string +---- edit* [edit-id] +---- edit-id? string +---- operation enumeration +---- target target-resource-offset +---- point? target-resource-offset +---- where? enumeration +---- value? yang-patch-status +---- yang-patch-status +---- patch-id? string +---- (global-status)? | +--:(global-errors) | | +---- errors | | +---- error* | | +---- error-type enumeration | | +---- error-tag string | | +---- error-app-tag? string | | +---- error-path? instance-identifier | | +---- error-message? string | | +---- error-info? | +--:(ok) | +---- ok? empty +---- edit-status +---- edit* [edit-id] +---- edit-id? string +---- (edit-status-choice)? +--:(ok) | +---- ok? empty +--:(errors) +---- errors +---- error* +---- error-type enumeration +---- error-tag string +---- error-app-tag? string +---- error-path? instance-identifier +---- error-message? string +---- error-info? Regards, Benoit > Dear all, > > Now that RESTCONF progressed, here is my > draft-ietf-netconf-yang-patch-10 AD review. > > > - I see one issue at https://github.com/netconf-wg/yang-patch/issues. > Is this integrated? > > - This is a comment for the RESCONF draft: > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 > > OLD: > Please see > [I-D.ietf-netconf-yang-patch > ] for an alternate media-type supporting > the ability to delete child resources. The YANG Patch Media Type > allows multiple sub-operations (e.g., merge, delete) within a single > PATCH operation. > NEW (change . by :): > Please see > [I-D.ietf-netconf-yang-patch > ] for an alternate media-type supporting > the ability to delete child resources: The YANG Patch Media Type > allows multiple sub-operations (e.g., merge, delete) within a single > PATCH operation. > > - Editorial > OLD: > An "ordered edit > list" approach is needed to provide client developers with more > precise client control of the edit procedure than existing > mechanisms. > > NEW: > An "ordered edit > list" approach is needed to provide client developers with more > precise client control of the edit procedure than existing > mechanisms [RESTCONF]. > > Btw, is this more precise? Or it offers more capabilities? > It's only when reading through the doc that we discover the advantages > versus the plain patch > - ordered collection of edits, while > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 > is for a single edit > - an edit operation (create, delete, insert, merge, move, replace, > remove), while > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 > is for create or update > - patch-id > - etc... > I've been missing a section about the advantages compared to the plain > PATCH somewhere at the beginning of the doc. > > Btw, I guess that nothing prevents a RESTCONF server to support > simultaneously the plain PATCH ( > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6) > and the PATCH in this document? However, doing so, would provide a > useless audit log, since the plain PATCH doesn't have a patch-id > leaf patch-id { > type string; > description > "An arbitrary string provided by the client to identify > the entire patch. This value SHOULD be present in any > audit logging records generated by the server for the > patch. Error messages returned by the server pertaining > to this patch will be identified by this patch-id value."; > } > Worth writing some text about it? > > > - Terminology > Same remark as for the RESTCONF draft v13: RESTCONF server, NETCONF > server, server. > "Server" according to the terminology section is the RFC6241 > definition, so server = NETCONF server. > > A "YANG Patch" is an ordered list of edits that are applied to the > target datastore by the server > > So this sentence contradicts: > It may be possible to use YANG Patch with other protocols besides > RESTCONF. This is outside the scope of this document. > > Please apply the same changes as for RESTCONF > o RESTCONF client: a client which implements the RESTCONF protocol. > Also called "client". > > o RESTCONF server: a server which implements the RESTCONF protocol. > Also called "server". > > - Terminology: > > > 1.1.2 > . > HTTP > > > > The following terms are defined in [RFC7230 ]: > > o header field > > o message body > > o method > > o query > > o request URI > > > Throughout the doc.: message body => message-body > https://tools.ietf.org/html/draft-ietf-netconf-restconf-14 mentions: > - header and not header field > - message-body and not message body > - method referenced from RFC7231, not RFC7230 > > > - Inconsistencies between the RESTCONF and PATCH terminology: > draft-ietf-netconf-yang-patch refers to the RESTCONF "YANG data > template" definition. > > However, in the RESTCONF doc: > YANG data template: a schema for modeling a conceptual data > structure in an encoding-independent manner. It is defined with > the "yang-data" extension, found inSection 8 > ._It has a representation with the media-type > "application/yang-data+xml" or "application/yang-data+json"._ > draft-ietf-netconf-yang-patch mentions: > o YANG Patch: a conceptual edit request using the "yang-patch"_YANG data template_, defined inSection 3 > . In HTTP, refers to a PATCH > method where a representation_uses either the media type "application/yang-patch+xml" or > "application/yang-patch+json"._ > > Same remark for: > > o YANG Patch Status: a conceptual edit status response using the > YANG "yang-patch-status" YANG data template, defined inSection 3 > . > In HTTP, refers to a response message for a PATCH method, where it > has a representation with either the media type "application/ > yang-data+xml" or "application/yang-data+json". > > > - 1.1.6. Tree Diagrams > Should be renamed to "tree diagram notations" > > > - Is the YANG Patch valid for both YANG 1.0 and YANG 1.1? > RESTCONF is: > > This document defines an HTTP [RFC7230 ] based protocol called > RESTCONF, for configuring data defined in YANG version 1 [RFC6020 ] or > YANG version 1.1 [I-D.ietf-netmod-rfc6020bis > ], using the datastore > concepts defined in NETCONF [RFC6241 ]. > > Apparently, the YANG patch is only valid for YANG 1.1: > > There is a need for standard mechanisms to patch datastores defined > in [RFC6241 ], which contain conceptual data that conforms to schema > specified with YANG [I-D.ietf-netmod-rfc6020bis > ]. > > - Section 2.1 > The YANG Patch operation uses the RESTCONF target resource URI to > identify the resource that will be patched. This can be the > datastore resource itself, i.e., "{+restconf}/data", or it can be a > configuration data resource within the datastore resource, e.g., > {+restconf/data/ietf-interfaces:interfaces". > What would be an example of the datastore resource itself? > > - I received this feedback, directly sent to me. > > > 2.2 > . > yang-patch Input > > A data element representing the YANG Patch is sent by the > client tospecify the edit operation request. When used with the > HTTP PATCHmethod, this data is identified by the YANG Patch media > type. > > What does data element mean? Where is its definition? > > 2.2. yang-patch Input > Should be yang-patch request or something that someone not > familiar with the netconf RPC concept can related to in the HTTP > world which this I-D is for. > > 2.3. yang-patch-status Output > Should be yang-patch response. Same reason as above. > > - > section 2.5 > > | remove | remove a data resource if it already exists or no | > | | error | > +---------------+---------------------------------------------------+ > > NEW: > > | remove | remove a data resource if it already exists or no | > | | error | > +---------------+---------------------------------------------------+ > > First, after reading further below, “or no error” could be removed or > replaced with “if no error”. > > - modify/replace the entire datastore > > Each YANG patch edit specifies one edit operation on the target data > node. The set of operations is aligned with the NETCONF edit > operations, but also includes some new operations. > > +---------------+---------------------------------------------------+ > | Operation | Description | > +---------------+---------------------------------------------------+ > | create | create a new data resource if it does not already | > | | exist or error | > | delete | delete a data resource if it already exists or | > | | error | > | insert | insert a new user-ordered data resource | > | merge | merge the edit value with the target data | > | | resource; create if it does not already exist | > | move | re-order the target data resource | > | replace | replace the target data resource with the edit | > | | value | > | remove | remove a data resource if it already exists or no | > | | error | > +---------------+---------------------------------------------------+ > And, in section 2.1 > This can be the > datastore resource itself, i.e., "{+restconf}/data", or it can be a > configuration data resource within the datastore resource, e.g., > {+restconf/data/ietf-interfaces:interfaces". > > [this relates to this email thread "[Netconf] Is a 'replace' operation > on the candidate datastore always the same as 'remove' + 'merge' ?] > When I look at "replace" above, I'm not sure whether we can > modify/replace the entire datastore. So basically replacing the entire > config from a router. */ > /*I always thought it was only possible with NETCONF, with the support > of the :url capability. > So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I > was thinking that "A mechanism to dump and restore configurations is a > primitive operation needed by operators. Standards for pulling and > pushing configurations from/to devices are desirable." could only be > fulfilled with NETCONF. > Now, I'm confused. > > - Section 2.2 and 2.3 > YANG Tree Diagram For "yang-patch" Container*/ > /*s/For/for > YANG Tree Diagram For "yang-patch-status" Container > *//*s/For/for > > Not sure yet how/if we should document tree for YANG modules composed > of groupings only. Currently in discussion with the YANG doctors. > > - Section 2.6 > The server will save the running datastore to non-volatile storage if > it supports non-volatile storage, and if the running datastore > contents have changed. This will be done in an implementation- > specific manner. > You might to add that this is a RESTCONF feature, not a YANG PATCH one. > Indeed, from > https://tools.ietf.org/html/draft-ietf-netconf-restconf-15, section 3.4 > > Each RESTCONF edit of a datastore resource is > saved to non-volatile storage by the server, if the server supports > non-volatile storage of configuration data. > > What is confusing here is: what does "This will be done in an > implementation-specific manner." add in > draft-ietf-netconf-yang-patch-10 compared to RESTCONF. > Should this sentence be part of draft-ietf-netconf-restconf, and > removed from here? > > - > leaf comment { > type string; > description > "An arbitrary string provided by the client to describe > the entire patch. This value SHOULD be present in any > audit logging records generated by the server for the > patch."; > > I don't understand why it's not a MUST. Is this because this field is > optional? > So if it's not in the audit logging, we don't know if it's because the > field is empty, or because someone decided not to include it. > Do you want to say: If populated, this value MUST be present in any > audit logging records generated by the server for the patch. > > - I'm not clear on the atomicity rules > container yang-patch { > description > "Represents a conceptual sequence of datastore edits, > called a patch. Each patch is given a client-assigned > patch identifier. Each edit MUST be applied > in ascending order, and all edits MUST be applied. > If any errors occur, then the target datastore MUST NOT > be changed by the patch operation. > > In > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4, > if "edit2" fails, should edit1 be reverted? > If, by patch operation, you mean "leaf operation", then the applied > change by edit1 should remain, right? If so, if edit2 fails, would > edit3 be applied? > Reading further, I see in section 5: > If the entire YANG Patch > request cannot be completed, then no configuration changes to the > system are done. > Now, I'm confused. An additional example would be useful (only edit2 > fails). > Assuming the sentence in section 5 is right ... Since there are no > candidate datastores in RESTCONF, is this realistic to "test" edit1, > edit2, edit3 part of the > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4 > in order to populate the potential error message, and to revert the > command if there is an error message? > > And I see this diff between version 8 and 9. > > > > Surprised that, if there is any error, it's not a MUST to return the > "yang-patch-status" message? Maybe I missed the discussion on the > mailing list. Feel free to let me know. - Section 5. > It may be possible to use YANG Patch with other protocols besides > RESTCONF, which is outside the scope of this document. > Is a repeat from the intro. - Editorial OLD > case global-errors { > uses rc:errors; > description > "This container will be present if global > errors unrelated to a specific edit occurred."; > } > NEW > case global-errors { > uses rc:errors; > description > "This container will be present if global > errors are unrelated to a specific edit occurred."; > } > Regards, Benoit (OPS AD) > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------1F7217D1FDC8B5BF17F110C2 Content-Type: multipart/related; boundary="------------AC3046D55907173764757B95" --------------AC3046D55907173764757B95 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
One more point.
The trees in section 2.2 and 2.3 are not correct.

pyang -f tree --tree-print-groupings ietf-yang-patch@2016-07-07.yang
module: ietf-yang-patch
groupings:
  yang-patch
     +---- yang-patch
        +---- patch-id?   string
        +---- comment?    string
        +---- edit* [edit-id]
           +---- edit-id?     string
           +---- operation    enumeration
           +---- target       target-resource-offset
           +---- point?       target-resource-offset
           +---- where?       enumeration
           +---- value?

  yang-patch-status
     +---- yang-patch-status
        +---- patch-id?      string
        +---- (global-status)?
        |  +--:(global-errors)
        |  |  +---- errors
        |  |     +---- error*
        |  |        +---- error-type       enumeration
        |  |        +---- error-tag        string
        |  |        +---- error-app-tag?   string
        |  |        +---- error-path?      instance-identifier
        |  |        +---- error-message?   string
        |  |        +---- error-info?
        |  +--:(ok)
        |     +---- ok?            empty
        +---- edit-status
           +---- edit* [edit-id]
              +---- edit-id?   string
              +---- (edit-status-choice)?
                 +--:(ok)
                 |  +---- ok?        empty
                 +--:(errors)
                    +---- errors
                       +---- error*
                          +---- error-type       enumeration
                          +---- error-tag        string
                          +---- error-app-tag?   string
                          +---- error-path?      instance-identifier
                          +---- error-message?   string
                          +---- error-info?

Regards, Benoit
Dear all,

Now that RESTCONF progressed, here is my draft-ietf-netconf-yang-patch-10 AD review.


- I see one issue at https://github.com/netconf-wg/yang-patch/issues. Is this integrated?

- This is a comment for the RESCONF draft: https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6

OLD:
   Please see
   [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting
   the ability to delete child resources.  The YANG Patch Media Type
   allows multiple sub-operations (e.g., merge, delete) within a single
   PATCH operation.
NEW (change . by :):
   Please see
   [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting
   the ability to delete child resources: The YANG Patch Media Type
   allows multiple sub-operations (e.g., merge, delete) within a single
   PATCH operation.

- Editorial
OLD:
   An "ordered edit
   list" approach is needed to provide client developers with more
   precise client control of the edit procedure than existing
   mechanisms.

NEW:
   An "ordered edit
   list" approach is needed to provide client developers with more
   precise client control of the edit procedure than existing
   mechanisms [RESTCONF].
Btw, is this more precise? Or it offers more capabilities?
It's only when reading through the doc that we discover the advantages versus the plain patch
- ordered collection of edits, while https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6 is for a single edit
- an edit operation (create, delete, insert, merge, move, replace, remove), while https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6
  is for create or update
- patch-id
- etc...
I've been missing a section about the advantages compared to the plain PATCH somewhere at the beginning of the doc.

Btw, I guess that nothing prevents a RESTCONF server to support simultaneously the plain PATCH ( https://tools.ietf.org/html/draft-ietf-netconf-restconf-14#section-4.6) and the PATCH in this document? However, doing so, would provide a useless audit log, since the plain PATCH doesn't have a patch-id
      leaf patch-id {
           type string;
           description
             "An arbitrary string provided by the client to identify
              the entire patch.  This value SHOULD be present in any
              audit logging records generated by the server for the
              patch. Error messages returned by the server pertaining
              to this patch will be identified by this patch-id value.";
         }
Worth writing some text about it?
   

- Terminology
Same remark as for the RESTCONF draft v13: RESTCONF server, NETCONF server, server.
"Server" according to the terminology section is the RFC6241 definition, so server = NETCONF server.
A "YANG Patch" is an ordered list of edits that are applied to the
   target datastore by the server
So this sentence contradicts: 
   It may be possible to use YANG Patch with other protocols besides
   RESTCONF.  This is outside the scope of this document.
Please apply the same changes as for RESTCONF
   o  RESTCONF client: a client which implements the RESTCONF protocol.
      Also called "client".

   o  RESTCONF server: a server which implements the RESTCONF protocol.
      Also called "server".

- Terminology:
1.1.2.  HTTP


   The following terms are defined in [RFC7230]:

   o  header field

   o  message body

   o  method

   o  query

   o  request URI


Throughout the doc.: message body => message-body
https://tools.ietf.org/html/draft-ietf-netconf-restconf-14 mentions:
	- header and not header field
	- message-body and not message body
	- method referenced from RFC7231, not RFC7230
- Inconsistencies between the RESTCONF and PATCH terminology:
draft-ietf-netconf-yang-patch refers to the RESTCONF "YANG data template" definition.

However, in the RESTCONF doc: 
      YANG data template: a schema for modeling a conceptual data
      structure in an encoding-independent manner.  It is defined with
      the "yang-data" extension, found in Section 8.  It has a
      representation with the media-type "application/yang-data+xml" or
      "application/yang-data+json".
draft-ietf-netconf-yang-patch mentions:
      o  YANG Patch: a conceptual edit request using the "yang-patch" YANG
      data template, defined in Section 3.  In HTTP, refers to a PATCH
      method where a representation uses either the media type
      "application/yang-patch+xml" or "application/yang-patch+json".

Same remark for:
   o  YANG Patch Status: a conceptual edit status response using the
      YANG "yang-patch-status" YANG data template, defined in Section 3.
      In HTTP, refers to a response message for a PATCH method, where it
      has a representation with either the media type "application/
      yang-data+xml" or "application/yang-data+json".

- 1.1.6.  Tree Diagrams
Should be renamed to "tree diagram notations"


- Is the YANG Patch valid for both YANG 1.0 and YANG 1.1?
RESTCONF is:
 This document defines an HTTP [RFC7230] based protocol called
   RESTCONF, for configuring data defined in YANG version 1 [RFC6020] or
   YANG version 1.1 [I-D.ietf-netmod-rfc6020bis], using the datastore
   concepts defined in NETCONF [RFC6241].
Apparently, the YANG patch is only valid for YANG 1.1:
  There is a need for standard mechanisms to patch datastores defined
   in [RFC6241], which contain conceptual data that conforms to schema
   specified with YANG [I-D.ietf-netmod-rfc6020bis].
- Section 2.1 
   The YANG Patch operation uses the RESTCONF target resource URI to
   identify the resource that will be patched.  This can be the
   datastore resource itself, i.e., "{+restconf}/data", or it can be a
   configuration data resource within the datastore resource, e.g.,
   {+restconf/data/ietf-interfaces:interfaces".
What would be an example of the datastore resource itself?
- I received this feedback, directly sent to me.

2.2.  yang-patch Input

   A data element representing the YANG Patch is sent by the client to    specify the edit operation request.  When used with the HTTP PATCH    method, this data is identified by the YANG Patch media type.

What does data element mean?  Where is its definition?

2.2.  yang-patch Input
Should be yang-patch request or something that someone not familiar with the netconf RPC concept can related to in the HTTP world which this I-D is for.

2.3.  yang-patch-status Output
Should be yang-patch response.  Same reason as above.

-
section 2.5

   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   +---------------+---------------------------------------------------+

NEW:

   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   +---------------+---------------------------------------------------+

First, after reading further below, “or no error” could be removed or replaced with “if no error”.

- modify/replace the entire datastore 

   Each YANG patch edit specifies one edit operation on the target data
   node.  The set of operations is aligned with the NETCONF edit
   operations, but also includes some new operations.

   +---------------+---------------------------------------------------+
   | Operation     | Description                                       |
   +---------------+---------------------------------------------------+
   | create        | create a new data resource if it does not already |
   |               | exist or error                                    |
   | delete        | delete a data resource if it already exists or    |
   |               | error                                             |
   | insert        | insert a new user-ordered data resource           |
   | merge         | merge the edit value with the target data         |
   |               | resource; create if it does not already exist     |
   | move          | re-order the target data resource                 |
   | replace       | replace the target data resource with the edit    |
   |               | value                                             |
   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   +---------------+---------------------------------------------------+
And, in section 2.1
   This can be the
   datastore resource itself, i.e., "{+restconf}/data", or it can be a
   configuration data resource within the datastore resource, e.g.,
   {+restconf/data/ietf-interfaces:interfaces".

[this relates to this email thread "[Netconf] Is a 'replace' operation on the candidate datastore always the same as 'remove' + 'merge' ?]
When I look at "replace" above, I'm not sure whether we can modify/replace the entire datastore. So basically replacing the entire config from a router.
I always thought it was only possible with NETCONF, with the support of the :url capability.
So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I was thinking that "A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable." could only be fulfilled with NETCONF.
Now, I'm confused.

- Section 2.2 and 2.3
YANG Tree Diagram For "yang-patch" Container
    s/For/for
YANG Tree Diagram For "yang-patch-status" Container
    s/For/for

Not sure yet how/if we should document tree for YANG modules composed of groupings only. Currently in discussion with the YANG doctors.

- Section 2.6
   The server will save the running datastore to non-volatile storage if
   it supports non-volatile storage, and if the running datastore
   contents have changed.  This will be done in an implementation-
   specific manner.
You might to add that this is a RESTCONF feature, not a YANG PATCH one.
Indeed, from https://tools.ietf.org/html/draft-ietf-netconf-restconf-15, section 3.4
 
Each RESTCONF edit of a datastore resource is
saved to non-volatile storage by the server, if the server supports
non-volatile storage of configuration data.
What is confusing here is: what does "This will be done in an implementation-specific manner." add in draft-ietf-netconf-yang-patch-10 compared to RESTCONF.
Should this sentence be part of draft-ietf-netconf-restconf, and removed from here?

- 
leaf comment {
           type string;
           description
             "An arbitrary string provided by the client to describe
              the entire patch.  This value SHOULD be present in any
              audit logging records generated by the server for the
              patch.";

I don't understand why it's not a MUST. Is this because this field is optional?
So if it's not in the audit logging, we don't know if it's because the field is empty, or because someone decided not to include it.
Do you want to say: If populated, this value MUST be present in any audit logging records generated by the server for the patch.

- I'm not clear on the atomicity rules
       container yang-patch {
         description
           "Represents a conceptual sequence of datastore edits,
            called a patch. Each patch is given a client-assigned
            patch identifier. Each edit MUST be applied
            in ascending order, and all edits MUST be applied.
            If any errors occur, then the target datastore MUST NOT
            be changed by the patch operation.

In https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4, if "edit2" fails, should edit1 be reverted?
If, by patch operation, you mean "leaf operation", then the applied change by edit1 should remain, right? If so, if edit2 fails, would edit3 be applied?
Reading further, I see in section 5:
   If the entire YANG Patch
   request cannot be completed, then no configuration changes to the
   system are done.
Now, I'm confused. An additional example would be useful (only edit2 fails).
Assuming the sentence in section 5 is right ... Since there are no candidate datastores in RESTCONF, is this realistic to "test" edit1, edit2, edit3 part of the https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-10#appendix-D.1.4 in order to populate the potential error message, and to revert the command if there is an error message?

And I see this diff between version 8 and 9. 
Surprised that, if there is any error, it's not a MUST to return the "yang-patch-status" message? Maybe I missed the discussion on the mailing list. Feel free to let me know. - Section 5. 
   It may be possible to use YANG Patch with other protocols besides
   RESTCONF, which is outside the scope of this document.
Is a repeat from the intro. - Editorial OLD 
           case global-errors {
             uses rc:errors;
             description
               "This container will be present if global
                errors unrelated to a specific edit occurred.";
           }
NEW
           case global-errors {
             uses rc:errors;
             description
               "This container will be present if global
                errors are unrelated to a specific edit occurred.";
           }
Regards, Benoit (OPS AD) 
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--------------AC3046D55907173764757B95 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAB/QAAAHdCAIAAACMotZgAAAgAElEQVR4nOzdaVwTWb4//r53 7vx/98703LnTM6OJ2m1ru3W3a6vtviuigAuCoCiKuKCgIogiqwiIqCCKiCigKBFXFBERNxBF EWVxgewhC2Sn2EG21P9BIAmLIjQKbX/eL56QOnXOt05VonyS1PmKBAAAAAAAAAAAAACA35Wv iouLCQAAAAAA6DEqKiq6+88EAAAAAADo6RDuAwAAAAD0LAj3AQAAAACgXQj3AQAAAAB6FoT7 AAAAAADQLoT7AAAAAAA9C8J9AAAAAABoF8J9AAAAAICeBeE+AAAAAAC0C+E+AAAAAEDPgnAf AAAAAADahXAfAAAAAKBnQbgPAAAAAADtQrgPAAAAANCzINwHAAAAAIB2IdwHAAAAAOhZEO4D AAAAAEC7EO4DAAAAAPQsCPcBAAAAAKBdCPcBAAAAAHoWhPsAAAAAANAuhPsAAAAAAD0Lwn0A AAAAAGgXwn0AAAAAgJ4F4T4AAAAAALQL4T4AAAAAQM+CcB8AAAAAANqFcB8AAAAAoGdBuA8A AAAAAO1CuA8AAAAA0LMg3AcAAAAAgHYh3AcAAAAA6FkQ7gMAAAAAQLsQ7gMAAAAA9CwI9wEA AAAAoF0I9wEAAAAAehaE+wAAAAAA0K6v+EWFHIWwW36kRfLu/rsJAAAAAKDHQbgPAAAAAADt +moVN2ghy7tbfh5Is7r77yYAAAAAgB4H4T4AAAAAALTrK0O270SGc7f8JEoyuvvvJgAAAACA HgfhPgAAAAAAtAvhPgAAAABAz4JwHwAAAAAA2oVwHwAAAACgZ0G4DwAAAAAA7UK4D18AqVjI 43F4fAmhLOruWgAAAAB+M4T78EdSV1dTTkgkRHntu7rurgUAAADgdwXhPnwBEqM8VlrMXWV3 hRBKu7sWAAAAgN8M4T78kXA5LwOs+n1rdextKr+7awEAAAD4XdGG+/q8Y85FOUlluanluanl ucmlaVflYfNYrp0J7tkB8woeXS19k1ze2Jv2pyzjkuzSZobzNIT7f3jcR7RzHiv0F5nqO19J zuI2PioXEdmR/lstTfT19fX1F5laOF8RaDa+R9zJHQsMxhhanicEkk9eNgAAAMCn1rlwX5Tg 52dvbtTE+mjyI2ZJJ/9KECXQ/OwtjVoxtjSyOZfMV3a2X/hyVCvyWVE2NquNjeyPhyaytBtk aSlRntZNl4z98Xu6G9vCZDzbu+Q//7Rkf/Z9zqetGQAAAOAL0xjuG+SHuinTUqsLnxQ9uqS4 H6F4FV8iELzLDpeGLePs7XC4zzmxUM7Pryt6VfrihuJ+hOanlJ9RLckrTfZkOM/s1nBfmH3v 7hlf5/c5dCb89qvuqu2TERQK7kfv8/R2dnZ2dvYJioh5TkjkRM6tUxEHnZ2dnV08vf2vZr3i fL50XJCZlHhk0yaDX/7HIOhKSl7jowoxQY+PDvJ1d3LaZLHY4Je+BkFszcb3yE6NPXU68HR0 OiGRf/KyAQAAAD61job7tWVy8cMQr02rN9pu2ebu7u6+0919qf5Ca3v/+If0TuXw9BAPS9MZ 05ZvdtfhaG1jrv/PoS4xb0TyznTaZWpLZeIHx0MCfL3a5H/U6+JrMVHVrTV2ORVJsjNuRp1U H+O+fVGPJdwisojz8tHZxuMOuPAwmfH53napKZGIko4c3TBl9JKdm09maDcU5766GxXg7u7m 5rpiQu8lOyN0N7ZFqRA+vODheeGRmFP0aWsGAAAA+MKow33/rdJHiVUiDpHkxvJcwHCeyAix EDy7/a5YUZ3qJTg8pzOf3E+5VpyyPz/AROdxfXHaufL8zJJ7W7r7k/vcR7ToXQum/0z5/yg/ j5k4Q0/X+EEDp67Qd4vvrto+GbaAHe1rOmnsv74dOGjUPBuXA0lEgZR4Er7bddmI0UO+/evg mWaHkp+8LfisRb1Jeh1k8s3S4Ctt5fdvkqKCTPouDW433AcAAAD4onQw3K8o4j66aDZugfWh E4+YMpIkyTKSTAlfP8fQeI9T5KtyklR19K8E4a3oE1Eh558KdR6rEaQ8PW3Td+z+W7ni7v3k frWSz47atElv6HcDhnw3fIqBrlkTpk4Y99USWuaXlhOrSPLlraM2ZsOHfPv3gWMMjXZe4maJ ycLM2zEOMw1G9/7ffsOn24ZFP/u8b7s01JMJ9lb2Ppvbyu8b6usS7EfZ+7Qb7gMAAABAJ6nD /Wu+stdpJY8iGM5zdD99L+Vya3gxwtC1XXOTfbedRa/TqrkpxLUecc/9t/ffHF3Wy/hYzIPc Zo8nuO9y3LlQJ9yXi4UCDp1OZ9DpPIFEJldIpQX5LDqdQafTOQKRWPtZcamIx2PT6XQmk8Uv UCgV8sICPodFp9MZTDqvQCJT6I4jL+TzOUy6BiufXyBt/rlzuUwi4OoMpJRLJQIWk0Gn0+ns fJGow/eXLyCIKJe5Vo4uZ27pPpwadt7Luq/leWa+uOkhhVJRwGcytPUxGHSWoEAqb3YMUpGQ x6Yz2EyuUKosFHDZ7Ma2TJZAKpUrWwyvkBaIeNoumVy+4MXtzof7SrlCIuAwGQx1b20sqFtE ELJCPofDpDM5PH6hQirkcFiNzZksfoFSqWjZqVQs5HE0JXKEooICiYjHojPodFZ+gVTaagcA AACALtfBcD+f/yrSimoVkcPj6j7MOull57rF9VpeJ8L9NtRLnkaf3Tr9/5lde8kluqC/3+62 w4Yd3htC0ps9yLn74sT6P+mE+w11tVWERC6VSCSKopLKd6p6sraMkMukEolEXqQofafZte5d ZXmRRCKRSCRFJZXvahpqaqtK5OoHFCUllTW64zTUVGk2SiQSiVQhJyprm011g0pVVaqQy5sG UqlUdRUEoZBKJBKpXEFUkXUNHT3m9MTQfVbjd9JIUnsOlKyG6CWj1oScvstuekhFku8qS4oU Eh0yori8utmCtXXvatQHLC8pq66orCwp0rYtK6+ubzG2qr62tkwul2kaKRSl1XXx2zsZ7qtU ZF1FGaHQ9FfUxoK69TVVZSWyxq2VFWVlRdrmJZXvalt22rg2r1TdRF6kLK1UNZ5umaK4vBIL 9gIAAMCXRR3ue8xk7pvP2juH4TxJm8UfXcDNef2Oe75rwn23iYzzESUFeVXJN2QePTrczzju u89njU64/+y8l/N8CoXSn0IxdbnxOJ2RcPvImnEUSl8KhaLv4kNL17S842u6ahKFQhk+dJRt CJPPyI48ardwJIVC6T+UYhpy4zFDd5zsSDu7hcMoGqPWbj+emNOslGcpV3abUCjfNg3Ef5EQ 5zhuyPd9KBTKZEsf/7sdPeaPD/fzOG+P2fw06GdNeX0HUcY7Bd/NYurumOjjaTGRMnDicKN9 CbwzziYzJja2HT7eKeFulrDF8IxbQYdXj9R0OczQ3sEvovPhPj+Dcd1Bb/D3AygUCoUyoo0F dWUE8SzCVl9/KGXE3FU2kfR7Xnr64xqb//jL1lCukNGy08Qoj5XzNCUucDtw7Ej84dXjKP36 UMavO37/DrPlDgAAAABdroPhfl1dTUVRYVFFTV2z6LI2/ribv0eXhfsFmVc9d80dOz+8kinv cCb9SbQZ7svSX9/w/GEJ7W1TuE/k58RaUX8dSqVS5y3fFfWwUky+9ls3bdRQKpU6Ybm+10PN rrzkqKBlVCqVSqUuczyfkqXMol/dMZVK/Z5Kpc5z3BWVpTuOMuvG1R3jqRrD9GasP/OaJHVu BkQ0NFzdq/fr+KaBVKoGVuQ6q7lDqVTqsIn61rEkv7ijx/zx4f6DM47L5lJ1jFq1MeAOW7cz 7oOsQGNqnz7UXx0Oxp85f9beWNv2YMCdghZjVxbmZftOnTrye3WbAWNmzvDLYZ2x6Wy430Cy IvzWzhlJpVKp1L79vjVpY0FdUWas7/bx1L79vjUJzo054ee7srE5lWriFJOa3bJTLudlwFoq dYi6xInmhi60umzfNZNHDKWO0t8UGMVuuQMAAADA75p2Qd0WP/q80D1K1ouiSGee19zfHu4z 904UPIuvkuQSt05ynXteuJ/z4t65fSv9Y3kijuhNVmbW4xccTUPB2+dPE06Hn/AwG7LE3tFi nc2q5Su3udJoUTSa64Z1XgHhN+mNLdkZd+/fOH7IxdFkiNGeQ2vMTVessffwodHOnD5tv2zJ wZiHj7kEQRASATvJz3y1lY29RyBNw3vrdssta93OJhFEU0At4NHTkqLCY/yWz7KwX7F8nYvl 8nlrXMMjo2g0191OXo6uN3MIoiMfJf/4cF8sLcxKuXLpiqa8M+E0l9Xmpg7OEYlpmh3ZGen3 j+1zXzVh2LQl8/TWOh7aH0Kj0Y6Fndgwf8R024P3EnVWLngSvnvn5jWr7H01XQa4bdu0cOTM X4b8Wf9IZ8J9mUDMeJJw+eJFGm3/lkVrTVovqKskCP7rRwnR7habDUePWbB+kulOvyMnaTTa aX9Pl6VTx689cvZpLq+xt8aFfK1tnF2ONFW422rDqllTZ84e/ZOF+6mLCdlcNhbsBQAAgE+v cwvqtiBKOHAq4vLZR+KyLgn35cnx/tsW/Wp5SERKatpv/jlow/0ykkyJsA+6eCeL+Y4olTIf PBeVVTRWWVNRLHoed+92yJ7lNpuNV7oGbjSavsrp1NmIuLhQ/wNudjvOcUjlO5IkyXJZPvPJ 5bi4wI0TVznaWW7fY21mutUzLi4mLu7QLqf9B0ISRI0jMxOOH9ppZbr1QJxGeGDYzg0zFu+P 4UjEja1qVCrR25R7d8Oddzpt/tXUNcpmkfEaJ5+giLi40IgIt6WLzqdwlKUdO+aPD/elvOwn yXE6jrl7bdm6wjEyhSTL1a3KpQQj8cYNh0UzFxhO17ey2eUaEhcXdyMuzmObhbHlhsDITO3A hS8TaG7mMy09T0fFqPu7cCbMfdW05ZP7fzt3eyc/uV/Gy3uefCcu7vyJgw6T/rQ8qPWCupWE KPfphaAAk35zFq2cvHzXNs/guLi4G9evH9+w0NTK2flCukjTVpaWEuW52cJ625E42pW4uLi4 c8f99tosNDKfOWLI0o27Q66+YOSXd2y6AQAAAHq4tsN9g/xQN8Wj+5WvDwn3LWZ1wT15prC8 LZS8jHf8RPnl9YweE+4HGPQabWSy1s7Z2XqNidEvfVYdofNy226dz6fHuv86bqGRkdkW98Nh t9IJQk4Q2fG0pKR7qVzdlnnpN4Jsfxo+Y4X5+m3+4TfTcghCViB8du7orbScbCFBCN5yEo+v Xr5ss8/Zm2k6nwPPjr+x38Fmw441F57zdZeFlfKJx26WxgtnzTbbsCNgX3S6SCwniOzHSUnX YlIZnQn35xtOX2Khu4DwukXLjBY2D/dbkQmIZwG2c4zW7g65wNPdkHrv0nZ96vcT9dwDrr/K FhIEwS9g3Ti34pdlTtEh94QEQRAKMcG47edgs2Wn/+kEbd7PeHz9nKup8eQB/29Bp8J93SJO 7ti7vnW43yj3mo/fitF9f1lhfjQpLU9IEISYmZYasW3uyLWHEtKyCIIgCCmf+SzQ3G7zLs/w B4+bTign5Xyoy7J506cOneYVxysQtFMFAAAAQNf4jeF+4/q6uz3D4tJzO/zZ8LaVPA895mA1 cWnwK5Ks7Jouf7PbDhtWGo813ODl5ezltWwSdYljWFL6e1vnxbpvsZo5a+EWB3f3CymFRUqS VLJev4yPuVdIlmpv71JBkpnBS/VNDQ3NtnsGht55RZJVJCl6/iA9+cFzOUmqVCQ76aTPzvUO vqF3WNrulayCxOPuS5dahCbd5za/3T//WsxBq7HjFm7Y4OEclvKSU0SSSqX05YVj95iy0g5O ZnpiqMOSvlNMvLycNQsI7962d9mPlCUBOuF+W0RJsftsjWasDxKTcu3xKhsaztvPGDVn0lr7 wIfP5SRJqkiSmR6y2cV21/oYRWOrEnrKxSDbdXaeMdqViiuVouxo1z2Lhw7R3/ob77mvYDw7 v/RPa0Jah/skSZIVguwM56Hjx+vPczoTnVFAkqSqoV7+LMhtjd32vdGaMy66GxzubrvJ69J9 MVlWS5IkWSHMeX7exXrxsIEjbfdffSlso28AAACA37c2wn193jF3xeObFcwE5TU9lkeX3G1/ Njs4uKKIXZUeKgmZ2HPC/UPzew0cPWbiDD29GVPGTR/5w6pAxgfC/avuvw6Ztc73SEJO200a 5aXfOLRlxNBxjtG3X3Jab5blJD73N/xx48Xraa225sRcDrQfbnwyi1co0zyoDvfnz1qy4ciZ tJZ7dJA63J86ZdCo8bprCE8aMfrXGS3CfYW0kP7o2q1rMU3Ox8T428yaYbXt8MlM3T5T713Y ufi7SVuiOc81b3IUsIioFavcIw/H0QmCUBZyBLGbzLcGHY5uecZFGXG3dk/9v0VHP3W4f2C9 /giLqId8SdN6wTze2xuuY00CE1LSCIIgxPy8lINzpnqeu3On2VsXBCcpKNDGcMA0rxsI9wEA AOBz+S3hfk1xITf1YtA2oxWeF29nFnbRXw3lr6N2OK1fNXf/yy7qsCvcdtiwZNp3w6cYGOgb GEz9mWK4I/LD4f6aVYYWK8M/fAjqcH/KIks3nwRm680qVUP5VZutroFOF1ptLeM3PNw8d9WR 0wl5VbqP86/FeK+aNGmlTwopLvvYg3uP9MRQ2wV/HzjGwEBPs4aw3kyDMZT/XXiwRbhP5Ofk PIrXEXF45/rVM01cM0mx9i0FZUPDeftJUzfuuRSre0Dpx2nB3iYn6OrfKl9Fhh/ZZ+LxqOVs NNQJI1aYrN/zycP9PcMmmhwKustuWi9YRZK5V/d4Htp78k7jr7JEn13+rn5Romb7VktyGUEz x0zevg/hPgAAAHyJmoX7kxh7ZrO8XYpykqvYt4tiuyLWV//4z+feffyuklV25qDQuQeF+9rb 8jBe3D7vtXBLJIdPJ+TSggIRXyQmCJ3FWfP59Jvuv5oGxj980k6/eek3Tu+avOoEu+33CfKf xd7cNdn0BPthG5sf34sNMJvsmcAR8TWPqcN9u8CDEe2N3L6PvS2PQiZhZ6YEm/WfMPhfvRr9 u1evb/7239/NWN8q3I8NMJ+yt1nNzcN9aX7eY7fxix2C1b828yap8/fc1y2ivXA/zGP9mmjd rS3C/TfMnCCzb5Z6X0lp+QZK7rVrAQ4TpnndRLgPAAAAn0unw/2ayhJe8tlTOxZS117N4XXd srd1OVdcTDat3OL8oMu67ALa2/JUkuSrSKtdEXHJmWRDfW11mZyorGu+AgGZF+vudcgjNLGd TtXhvk3wxaTnbW1WNTTkBS/1Cr4Y2sZmZUNDtMPSfeGXXwh0H+Zfizl1yNixvZE/ykfdlkel Ur0rVdwLsF436ZveWv/+5u99B45sHe5H2y9uVXPzcJ9/zfWAi63mV62GejLBvpP33NfRbrj/ wuWnjREMna0twv0Gkkw4ZmXvuFn9a7Od6zJcjOa6BCDcBwAAgC9Rs3B/DtsnvKyAU806I7/Y RZ/Zd57IcJ7ICVkoZXPqFc8LTzkze2a4r5BLCgXs/EKlUkHkJBwN9N9+4DJB6Nyk5o8V7uel XDm6YnA/w72RsSm5jXJyc6/7Llto54BwHwAAAODT6nS4nxW1y2GVwTSHyyJlZU1d1y17yz7t bbZm5fqg69Vd1mUX0Ib7DSRZU1FUXFFVXUMWien3/KZaXWDyec1a/5HC/YaGB55zFy1fv+lw QqHW8/jjbvZ6CPcBAAAAvhzacH8pLzi0+C29Kj1EGrWc69N1H9t31s8Pdy9TKmsYh4XBBoye Ge7renndz8fDyu38pwn3ZdmJz/0Nftx08Xoat+W2nJjLR95zW57PGu5np948vmmmpdeN9By+ Zg6kBPH4+KrFDo4dDveVhRz+tY3vuy1PgvPnuC1Pe+F+IT8v+eDstm/Lc8TGCLflAQAAgM+p c+F+ZuQOt907dx69nvJWqlJ1wRq6GqJLm9ausrPyS5J2Yae/nTbc16UQvYl3Gbok/C2n+R3o uyjcVzWUXbXZ5ha4q83b8iRvmWcReDohr9md9D93uF/a0JDsu2Lz3iNX7ufrfnuD/4x2wGVh Z8L9xtvyeL7ntjwbPvltedoL91UkKU30fs9teY7OGjN5uzfCfQAAAPgSNYb7y/lhR5WpLytz wqWnTDh7JzKcJzI8ZzBDXCXX9nD9l7fM630XcSN9ZXdDFXfDZJds+Ic/GO77Wghv3nxXKqu8 uo3f7D0DnXBfRhDpCaePHHJ29vAPOZ7ILJB2ZJnYzummcJ/gv+XcPmax3HR/VPJTnfV0CW7q vaPuuzbar45O54tbLaj7WcP91HuXvEx+tDyWxs9Tp+FilvBFTPDeTUtGjV9u2+Fwn1CICcat /Q6bnTyPX36izc6FWXfjDq43nTLwMyyo2164T0j5zKeHzbZu2X/w8jPtmr/Z8dG+lvOxoC4A AAB8Xh0N96sI8ZtL+9wctuw9GXdfu4SugpH8KO1hBpskmyf9tSQpzrgcEubv5XU06lQS+4Pv BNSSpPj2zukrN/u4x4re36yA8/JmlJeXl5dXUNyrtwWfZc3d7gj3SZWKZCWe8N650zes2S3u Kwtk6THHTZZanrhzj9NqQd3PGu4rGxqi7Wes9T5+73lJU82K5w8v+tubGC2c3JlwnyzOTY4J 2r7J4cRDsaKscTXemlJpwb1jnqY/D13wyRfUbS/cJ0mSFN45Fu6xc6v/vTckWd00M9zbhzcu GTZwpK0vwn0AAAD4En1lyPadyDnipXxJryWkVal7C887is46is46iq64i5+/qZU8Ep3e1TKv D94gfPq2nqxVkWQt+7T03IfCfdapzeIsZq0iV+67kev8nnC/kCDOueqNGPzVV38ZOHmix2O2 UPahP3d+MzE7O+vqoZCNk/8+aZOTb0hMM0Gua2w2rmwK9wveZj++ExsTERHqbj5k6nqP/QfV rS5eiYl7ms0RNcbFShkhePk4Me5qzInDbluXDZu1+VT4CXXLy3HX7mSypHLNIUkErDv7F+xw 9vM8ojPskT27NuywcTmTRBBSTZEPY2POR8T4m802XG+17aCmbWxydg67rRj7Q8fME+fcunbF 0XT03KXLt/smPHhMJ2QKgvPi3oNgO8eVev+c7XQy4vYzJl9AZGckBOyeNX+1Z+TRyJiYmJiY iOBwD6vFhlOH9x04aeE6h8jGfQnOi+cPgr1drKf/aOF5+tLtHC5HQoh59OxbYVccp88y375u 38WktLcCglASxOPTTq72mza4BmmO4oSv0w6TCdNHfv/ncRuc/S48fJHHJcTSwuxHVy+r1/E9 vm/Hhin/nLTplJ96KmMTrj+mS+VKgiAIgs+jP70XE3MpJiYmJuaA7eKVeuNnO8ZEnouJiYmJ uZn8IJNLEEqCELxJTbzgscpuhd6cXdciE1+x+GJCzGJlxtNC3MwGTVnv6Xci+WUmlyBkIiI7 wm+djZ3D3v2aEn3stlrr/zLHELflAQAAgM+pY+F+hVyUet5p0n+MWOzgFEDTWUA11HXFlp07 j99uGe5XkmRmiPGPY/7+1Vf9Z41xuN3Q8P5wv76ELLnlpTdho1tUNOMDRTxPCrOe+dVXX331 VX+r8xczFB2ov+PqqkpL6A+T/YznL1k1f3NAfDO0s8e9TfsuCXnNYZMkWVNcKsp5GB+fEB/q amaxbsWWvZqGd5+/ZEjKNZ1WSQro6ffjr8bHB9lMWrBp1z5tv/dz6IXFumvkMm4dDN1nt+2g 7rAnIvc5GBn5XGKLxU1FFtMfJt9NiI9wcbJbN3mpduQ7qS9f5JeTHaJSkbLcnKcnvLZYzB1s vDM+/i67RF5BVsj4zDthcY4TB8yx2ep96dlrvowsVTU8PG1ltm37/n2R6gFvxp9w2blx8ZQx o0YOnbI8KD7hbYm8giTLZcXMOzdvOi6eYLF1d8i1l8z8clKlapC9ffT0hM3OTaum2J65lcwo KKuuIcmCl7diPFcu2hZ09sJVdadXoiOO2BmYTx3Qb/yShbYnHzzOKyBVNaSMl/NUvY7vzbgb nosHLF69zTZQvcet+KdsoUJ9bdeoGkRvH92/r568k4cdJ/3nHJujPqfVE/Tw1ouCksoakqwk CvKexRwLXP6t/raTPpdeveYXk3VVDcV5GQ/DPUxXrFtp6/fw8YsCsrKWJGVpKad87JZv3xsf f7lxCeHAsF3Lp5rN/GnUdtyWBwAAAL5IXxmyfSdKUo5VyJR1Za1+SpR1wgfCUPuWkX3QWsHD p+/KpHVlyurXx8SRHwr38y/YKhms6txY9r4VjPeF+2KCuLR/+YyJvXp9P95ggf8zjkj+oT93 fjPGraOBlsN7vdfEmeZ+jffcz4k8arugjabUAb3GOh5Nymz88L1MQDw7YKs/bkjrlt//+uNC /3iOSCcalhHEs0hb/QXNWuut9qYlNS8yYHXbRY5YczT4tu7H/j9CXnLeMeNhA/upe/h51grb y4RAQiT6mKyYoH7su169TPZcf/ycIAh+BuP6Dr3B/fs3DvjzkFEbQ9h3/bbo6Q/R7kskens0 7tynV69xa4/dTWQSuQ8vHjXu1TjOUAOjHVHpBKE+nU+jPJzm6hzGJEuLHQffHjUeOqBvr17z LX0v3CVyOW+Pbhg64Mc2D3v4nFG2l7lC9XsfTx9edDLu1atvmy0nrbHwv0sQMoJ4GrFFb/5g 9fEN7WVyIu4Jg6DHxx9a9UuvXpTGtn7+d5tmKTsi0Ga+dtJHWtl77A7CPfcBAADg8+pYuJ// 6FWQMZVK6d2G2cYOkQ9ahvtVJPk60nra3CG9e49bNs/zwYfC/SoJ+Wq/9TQbz6iHmR8qIiv5 3A7j3r179+49zv5KXJayA/V3XKWY/mr/lKkjvmvrkHv37j2kd++1Qa/4PJIklVn0K/ZTevdu o+mIldYHE1maTkW3r+9fMa51Mwql9zh7v7isgmYliLKu77dv1nr8r3p7Y0myWKfIHN/JbRY5 ZK61dSSL7BBVA/nA08G4cUgKlWp89M2jfDCNsWYAACAASURBVJL7MCpgqabjuSZOZx+S6q8X RPitnTO86Rh69zZ2jKZFXPPZPla7L8l9kKXdecS89YfPsMmG+rr7HnMax+k/qs/0A7Esqfqb CEXcrCtreo8d3LTH0Al9ra6+idxmv3Rs797jJ+h7xZINxeT9CPuls9s8LdQ+vY2PXkjNV3dW X3fFY87YsW22HDqx77rYN4JikhRlXvPZpmk0d+fuc9lkZUFdlo/lpJ8HN7ZduC6WFKq/o6DM fHtp22TN6R6iN9PCOzvDZR7uuQ8AAABfqK8M2b4TmXtns30M2b5t/XjrMV2nt4zsXaYyPeez fQ3YvobsfbOZbh+8LY/7NNa+hex98xh7prw33C8iCLGQy2Lm5uYx2WyhTKks+qR/LykkIhGX kfteTBZXKCaIIoIg5IWifHYbTfPouUy+SCpvvH9QkZKQCfPZTHobLZl0tlCiVCq14xcRhKww n81u1prNFRZKP65IBk8kknTwzkUKqULEodPzGntgcfPFhLKIkAg5XGZjobm5HL5EJiMIQilX iPlsel5e04B0Bq9AIRXms9l07b6ERCho3DkvN5fJE0klCkIhFYs4uY3j0NkcfqFMPZMEISsU 8Nm608zl8oVNVakPX6FUiHh0ehvTmJuby2Ax8sVN14ZMKuZzcnPz2mzJ5HGFUvU8F2jmOY+e yymQyBSEQiIRcZlN+zJ5QqFm3uUFzU43g5f/IuYywn0AAAD4vDoW7te9qylTFLZNpiiuqG4Z 7qtIsqaiSCYXFxZKFfKS6g/dlkdVT9aUFsmIkorqmg8VUVNdUawuQkpUVtXUd6D+jmuor60p lckk7znoQnFhYVFZTV0dSZL1NbWVhKzNVhJlUWlVrabTuqqqUqW0zZbS4tKqmrpmJdTVVJUS zVpLpfKSSpJs+IgixfKioopaskNUKrK6pFihHVJRVvuujqyrrtA5+XL16SZVKrK2orRId3BF cUVFRWVjzep9ybpqnStHIi8qq6glVSpVdYmsaRxJoay0qrZefVANdTWVRYVSseYwpIVFlbUV RLFCqj78KlLVQFZXFCvanvDCwkJFWeU79UQ2qFSVJTJp2xMulhYWVdXWNZBkXU2lzjzLi4sr asiGelVNaZFUIm5sKy+qIhtXj25xusVymZBeleFiiHAfAAAAvlDaBXU//083L6gL8BGyr3j7 bjKaYnfjlVD6ab9OAgAAANCkcwvqAkALpYLsh05DZ68/dS5VWNV+cwAAAIDfGYT7ALpyntwI P+qsZbtli52zz/HbzEKZsv29AQAAALoCwn2ATlEqRSkXvbwOeDVydXXdtHGj/5Ws3MLPssgz AAAAwOeFcB9A1+ObJ1y26Gktsz8ccJPe3VUBAADAHwvCfYBOKSigX/A2MDA1aLTU0nbzOY6I eNfdhQEAAAB8Egj3AQAAAAB6FoT7AAAAAADQLoT7AAAAAAA9C8J9AAAAAABoF8J9AAAAAICe BeE+AAAAAAC066vwwqSjwpvd8vNazunuv5sAAAAAAHochPsAAAAAANCur4qLi7v7jxcAAAAA ANBCuA8AAAAAAO1CuA8AAAAA0LMg3AcAAAAAgHYh3AcAAAAA6FkQ7gMAAAAAQLsQ7gMAAAAA 9CwI9wEAAAAAoF0I9wEAAAAAehaE+wAAAAAA0C6E+wAAAAAAPQvCfQAAAAAAaBfCfQAAAACA ngXhPgAAAAAAtAvhPgAAAABAz4JwHwAAAAAA2oVwHwAAAACgZ0G4DwAAAAAA7UK4DwAAAADQ syDcBwAAAACAdiHcBwAAAADoWRDuAwAAAABAuxDuAwAAAAD0LAj3AQAAAACgXQj3AQAAAAB6 FoT7AAAAAADQLoT7AAAAAAA9C8J9AAAAAABoF8J9AAAAAICeBeE+AAAAAAC0C+E+AAAAAEDP gnAfAAAAAADahXAfAAAAAKBnQbgPAAAAAADtQrgPAAAAANCzINwHAAAAAIB2IdwHAAAAAOhZ EO4DAAAAAEC7EO4DAAAAAPQsCPcBAAAAAKBdCPcBAAAAAHoWhPsAAAAAANAuhPsAAAAAAD0L wn0AAAAAAGgXwn0AAAAAgJ4F4T4AAAAAALQL4T4AAAAAQM+CcB8AAAAAANqFcB8AAAAAoGdB uA8AAAAAAO1CuA8AAAAA0LMg3AcAAAAAgHYh3AcAAAAA6FkQ7gMAAAAAQLsQ7gMAAAAA9CwI 9wEAAAAAoF0I9wEAAAAAehaE+wAAAAAA0C6E+wAAAAAAPQvCfQAAAAAAaBfCfQAAAACAngXh PgAAAAAAtAvhPgD8cSkkIlE+l8UtkCqLlN1dDMAfj6RQwOVx8gUSoqiou2vpeWSFAj6PyxZI ijA7f0gI9wEA2tVQX1tTJpcrS8ura+u7uxiAP5662ndlhFRKVNTV4BnYSn3tu0pCKiMqqjE7 8Ikh3AeAPy563OGDm5aMNg5MEkpE3V0MwB/PrVM7l1ks3OgYS8gU3V1Lz5Ma5rDNwnDqzutS Od58/CNCuA8A0K4K4auXvjMmLnANTHxT2N3FAPzxMHNT91v9MMwqjJch6u5aeh7p25TzVoNG WJ2Kf1HQ3bXAF+53GO5LhUSS3x4bM31dW4PDb7/q7sq6nuhN6sMjlssWL9TX19fXX7fZ7WwS QUjbasl9RDvvuUIzHZ4RiWldVUR2/N1jds1m23yzhf/d/II2C/ld4Lx+dC7AUn/RQv2tIcmJ r7u7nI8jepV8P8By6aKF+ttOnL3zOyn6s3t8aueetfr6+vr6hsv01xy7nE7nfbD92yteHmbT +8z0jheIBR8zAOtZXrST8WIDfQvvoGtPGV1SNHwaqSd3OK/RX7p+927aa4kM2WjPdO3oxtkG E802xBBShPutPDiyfq3BpGGbLnZjuJ8SYudkqW+80dUl5o1c0a1fIHhxJfagjb6Rmb7ViRvZ bH53lvKZfOHhPjPhzrHtRrqsXXdEZnZ3WV1PpWoQ3drvu83cyMjIyMh80eL9lzkScVstqxX5 7CibzZbGRkZGRkbrNzhGppBkWZcUUVrYkOyzzdpcO9uLFhm5XE7KbrOQ34XqhnpWvPembeZG 691Dz2R1dzkfR1VfJ4z39t5qZrTBw+ns76Toz64g4ybNuelCtfQ+eCnjw5FYef7Lp7t/HDDO zut6lvBjBmioIzPCAnevM1rhsP3wHS5J1nRJ3fAJiNJvnN9ttGipyfqQZxm8rnk5hK6Wm3Nv z5K//H1JAPsJv7tr6XnE2UlhS/767yVHrqQJuqsGQdrlqF1Gi03MN4RmZPLLu6sMkiTJIk5p 4t51FiZGa/2O3sj6/f4XpGfq7nBfmJ1998wBZ2cX51Z8z8bcz+a23EFQyL1NWz1v+Yp1yzc7 aR25ejON2R0H8GmJWZkvLvq6u+xycjIznGSwYKH7eYIQt9VSkJmUGO7l5GTv5LR46gADK5cz t7qmhJwnp908li2csdZpu2PTbHsFeEeni8TyrhmhGwiYmYnnXDcuG/4/BnuunO2yt0E+LTHz ZUa0u6v1tOFLPPdHPe3ucnqorLiQsP1OTlvXbjKd2XvotqA7mR/O3wUvbydEHd8XkpgjkUs+ ZoD819yEALf103/+xXp70K3sjtQmZr54fumAh+seZ2dn58NRUUmN79BwUqKjj3k5Ozs7e3g7 n07JZooIQeaL2xEHnJ336LwgevtfSpHItF8vkAqJp+dCD+9zdnZ29j3mfylDIlMQBCF4mXg7 wke7X8A5zUAEQRD01LTLR7Vb94WGRd948eJGYOCNx7m8jn13gZ765HJQ61duZ2fn/eeSU153 9osQnJTbifeuJb3p5O46sq4Hh27XN19hMcf3aQGS4x4q8+GlE6ePRl3MIBR4/6WV3IcXL5w+ 5n8pQ6HstlT95bUjB6ymzF9kon/gmezTniR2RnzCnRv3XxJE20eb+yCZ5rZxg/GQwTsiHr1m fcpSeojfTbhfW0aKH1wOCfD3asU/LORShpgka1vuw35xcrf7SlP9ze5aAZGhd1jdcQCflkql kqdfuBDi6+5ua7d+ybD/WHo4k8Nuq2VNiaTg7tGj/l7u7utWLlwya/xOGkkWdUEJRUrWzYvL pi6x2mHtqJluD/fIRy85XdF996hpaBA9owXtWTx6icXmXXe6u5yPo2qolz+jRfuuWrLKRn93 UneX00MpGM8ehLu7u7m62+hNnmZt7R3P+GD7muJC4d1jgSdvJeeJSz5mgIZ6knHr2mHrRQvM pq8IyyLJqo+uTVVfK0+/QAs94OXl5XXw+P6rb+Ul1SRJVghzsq4HNb7unUq4kyUma4prhfcu HDt0QPuC6O3ldS7hFb9ZniV8ln491MvLy8vbx+tc2it+ceMR3Qs+etCncb9DIfuvvlWUvmvc pUJemx0TEujXuHV/kG/ogzzmg5s3HyQ9YSk/+ljUXdVk6XSl42B4bGxmxzrT6VZQQE8Nu/qW 0NTcWXJ62v2gTXuWjRrreCs+5/f7evVlk0k49y7s872QphQUd3ctPU+ZmP3igveBC0/fCj7q 9elTkL19FO+/du3MASMdEu68IT7lUOVKQW5y+PWc0oq2j7ZMXJFx5rCfxezZdrsCktr8vxB0 WneH+9zU1GiP1Xp6C/T09KYOHzZgAKXfiMl6evP09PTMPf0vpNJbtJflcDJ8F3832zH4zr1W wf8X7eZppx3W7w/3mxQQRJTLXCvHrgr3RZeCHayXz3c8nkMUflnhmIiZc9bsGyvv3024TxAE IeURqS4WW44cQbj/Ybwnry45jB7hENJeuN8ZEg7xaI+5gcPuDob7wpwHdw+YLhrb55t+Q4cY Ou0990z9eO41H3ezMcMG9PnnyAVzdl1NzeERnOQHka6r9PT09fTGDfymTz/qN9TRo4Yucn8u eq15C6KQS9z22rFu1vDv//W/3wzrZ+j3ME9SICfYD89GuprNnjF1FOVP/YaOG23upRmInZF0 /4Sr18alja+xenp6euarVlnu2m3a/0f7kHvZHZurzOvxh9fOmPoT5U+9h46bPEVPh+Uur/DE Z3kFHeqvUcZRd48Dtj6Jndm3teTgC4ccEe4D/BavL+zxdljz6cP957Tdrl47/C8RxPuHycxO P2Y01IGGcL9Heack2VG+NquXGxgYzJsyY+ygv/510C/T58wzMDBYvnWTTzybJKtb7FJ+LXDj OmvLQzEf9TnbLwaL/SJ4yX8sPf6ecF9HemLoPquuCvff5dKTfef+bZb3Lfbb0t/eXc/y7JiV l+PvJtxvlH/l/MnDZgj3P6yhlsw9ssvaZVt74X4n5V8+6+Ni1MFwv6GuRnBjr+eKcT8NHviP McbGB1IF8gqSJIvz7t/2WTp50N/+OWjcOKugU0lsskpWkxe513qFqYHBzHE/De3z169/GPP9 3ydsPJH4UDcAzbtx4/CaGZMG9/rP//rTqC0HY19Jq8gqKSsvcuO6FYsn/9R38MABg+ZtMj6Q KlRUkiRZLuUy7kTGulssXrZIz0Bt2aLFdr6+K+YZ2m3xS2B2aBKKBVV3925aPe2nvt8PHDBy goGW4cotNn4xj5glFe86fqNw6ePn13zGmF/iiroizZS+qThnOn/vXYT7AJ1Wynqc4jJ2isud TxzuS5ipl9wnrD5TIHv//++qSfL6ATu/Qwj3u1p3h/u6Xp7w3+GwzCr0MUHIWm+VioQ8Nj0j IS1y05gRm7yjbqfS6XQ6nc5g0nkFkk7crFcpV0gEHCaDQW/S6a4UMkUBl8lk0Ol0OpPL5RfK NZ87U0ilonwWnc6g0+l0Tr5ILCUIokhJyEV8DotJ18ERfPCz8J833FcfEYNBT9q/Z/0mwxUH b9Lpb9V1svN5ohY35FEoFQV8JoOpnUgWr0DZYiLlhXw+h0mnMxhMrkCqlCulYiGPQ6fTGQw6 S1AglUvEQgGHzmAwWYICPpfNYdIZbC5XJFXKhOq5YrC5XJFcqV1XUKFUFOTrjKvpqtUpVMgl IgGL3nSumWyugJmbc+ZzhPtKpUIi4jBZjKa5YbIFBQIuTyhsFTcq5RKJgKW9IpkcZn6BVMgW FEobLw1NuB/xUCzgNLVjcQWF4pbHrB6XwdK5vul0nlAiU/dUpFTIRBwOi0Fn53N4ggIuncGg 0zlCkVgsFQu46iuWI2x2TUqFQh5L95plcgWCVgN/FHmhiM/Ruf45+SKxRC6R8HUOn8Vh8SXq 0y0rFGgPt+kMiuTvX4GzvXBfqZCL85lsdQUM9ocW1FVI5erngqYqVq4ypTPhPkEQhIhJXFi3 cL2XR2Syduqkwhe0vT6O65YEPBdJdOazSEnIRDHbZqy0ttC3st0x6Qe9w8zUvBYTfv247YJf /+ubPoNnrYthpPMaszdBbkbksr+t8b0R/azxgAlxfrTDXIOZBkudop8TRGMvTyLO20//57/6 /NcPdkEdDfcJgiBycjMCl/1t8f6bac90Hr3lqbfG2tb2ZEbTK6FcIsrnNXu9Y3PyCyS6n89V yhRiPpvBYCR6Ozi4rt19ocXpLmjrdEuFXN1LkpVfKOALCoQ6jZODLxxynO39mM9lchqfDCwm W1DY8fWTZYUCPofOYDJZgkI+R/0CxeOJpEUyYX7jCxSPVyDXLnyqOSLtU5BJ5xW2eX8VhbRQ xKXrXPscnqiAx8gvkMpb/KugLkM7j/n5PL4ony0oLNIckVIpFwvZrZ77rbpSDywXcXWu7nx+ oVwmZLNZDDqTyxOKNf+WtRiXTmeyecI2T8pHUcrkOpPD+vCCus2LpLM4LJ6okMfgF0glHf7+ mEIhF+UzGEz13BXIipRNx9u6jBbj0ukMJosllMnaujWNUiYW83WmnMVl5RfIhGxBoUy3SHlh fj6n+TOBX1DQ8n88zc8gq/WCukUEISvMZ+v2xBVKJVKJuNlrNJvL1zzL2ngO6mxtRiLkcFm6 Pctenvuk4b5SIRcL2XQW43aI3XanjW5hdHqeZs5bPK004f7D59k6U8kVylpfDOqT0uyqZbF5 hUXap6BSQYh5HBaTzuTyhCKJTMRj0JlN13fzcbvH7ybc16XIeHvVZehQlytvRIrWW+ve1ZYX SSQSSarfjjXb1uyITJU0UZSUVHbq3hh1FWWEQibR0emu3pWWFMklEolEIpPIy6rq6hvUj6vq VbVlhFwmlUgkErlcUVpFkg0kSdZXV5U17tBIXqT40CdVP2+4r1I1HtHb2w9ObRs0aHtEak6u uk6pXEJU1dY16LYmyXeVJUWKZhNZWdn8OxcNNVVVJerJlhNl1dX1dXU15YREIpVIJDKiuLy6 pq6mipDIpBIZUVJUXKJuKy+pqq6urCoratyzpKq6tkF33Irm46q7qmt5PA0qVW0FIVdIdQqs qks9+hnCfRVJ1lWXEUXa60xOlBQXl5YRxZW1JKnSbapS1VUQhE6VkqLy8tLiyoryMs2loQ73 nRJUVYRCfVlJpDJFcVktWa/68LgSiURRVFqp6am+uqysSKY+oeWETCmTSORFyrIqlaqqVCGT SdS/6lyTddU15Urd7iQyhaKstq75wB+lvqa2sljn+pfLlWVVKlVNq8OveldHkmRD07XR7BKr rqtteE//HxHu11QUF2suHXnJexfUVanI6tJipc48FlVUMWM6Ee43yggL3b9n3p7rivKmqaur Jhipt3ZNWuKd2DI7q6t+ffXQXrNR470v7JzWf7XTmZPPWnyXif72kYfRV//d5+vBhh6Xr7C0 F39aoIWn03aXu9oDzrl2ePfC4f1nH7rFVzYOo2BUxqye+jPlL/2NV3c03CdJkqwlyfhAi21O OyLu6jzKunM8YP2Ucc7PmLLKBpIkyfq62spSuUTnBEol0uKKunrtnKtUZF1FaZFC9jrudoTz 8MVh6VksbeP3nO666ooynUtSqiwuKq2qKlaUv2tq3BTu30jnl2qfDEWlVTWtvhPWjvramsrG F6hSori4WCaRSKTykurq6srKxq6l8pJq7QuU5oh0L1tlaWlVGyOrVA3VpfLmV1kFoSwtK61q 8a9Cfe27Sp3ngkyhICqrCFlxufaIVCRZW1Va1Py5ryRaddVYZHWJzuUtLaqoqyovLS2SSaRy qaK8ur6hoa1xJRKpRKosqa5/73Pww1QqsraitEjeOLBUWvSBBXVVDS2KlBRVlBLKsrKysg5/ u0NFktUVxUqFRCKRKaTF1XX1DXVVpU0nsHkZLceVSCQSGVHe5ltWKlVDbUVRkVyqW2RFKVFR UaFbZH1NZWVx8w4VRcXVZH2zaWxxBqWSotYL6tbVVJbq9iQnysqr6xrelRbJpJqrQyotrqhX P8vq62paPAd1tzZTW12u+7SSE2WFbz9puK853ldpN8J2/GISlPXmpXZ8qbz03Tvtfzmawv1D 8bkV2n9E5ERZeauLQaVqqC3XPSkSiUSiLK1u9hSsKS8vlkukcqmy7F19VRmhlDddk83H/fL9 fsL9O37eqydRev2r1z/++uc///V/v/nXvykUCoVC6T+EYhoS2+oj/u0TvGTFOS4YNmAApUn/ oZ3siv4oL9hk+ODvKBQKZZih4faz6QTR+GcmIyEh0HIchdKXQqFQ9C19aHcJgpAJiGf+dgvG D6Po0HfxoaW/f4zPG+7npbw9tuynQd9S/vX3v/31r//9l7//k0Lpra5z8pqV/ndbtOa8PWbz 06Cfmw7l+2FjTE+wnzRPCrMjbG0XDKVQBg4abuSUwMsSJp7ztJhHoVD6DqKM3xV8N+vmOc9d 8yh9Bw0bvyt0i+GMBUMpAycuNtp/L/+ht63+uKEUysCJi40OpecXav6Cz+W8PbZx2EDNuJqu Wt2hiZ4Rf3jHOMr3fdTtfpy42GHfrZxQk88Q7vP59Fg/vcHjGq+zgYN+nLUrdI+BqYdX6J0W y0Twn9+M3TFuUP/GKikj541YE5LoNsP55P2LGQRB6IT7e5xjnOY1HfaoRY4nz7dccoLPp8fu nzdonPb6HkChLHeLT2vsKT/36f5588cNoEyxmmfhFGRMGdCPQlng7n/p3IMYJ2MKpR9F/WuG tsvb+9xWTNC9Zn9c5OgU3am1LrLCA2z0R2h7WmDlf+laetxV+3EDv9Mcvt647Vf5BTKCINLO uOyc22zkyUudAp4Tkve9s9BeuC9iZsesHzz1JwqFQqH8MPlDC+q+vZ99xHjw9/00Vf26+TT/ jlMnw32lgijk3T+8ausuz13RTXfLSfBydtpl5nWNI5IpdbMkKY946rN2orG1R3j4najIjb/8 w+T0zactPq56/bjtlrWj5jp7LPpmouvxB6/Um1uG+0IGccFa38rD7WQSh18o0yR6soLCV7fu htr89POO0K4L9yWC84FuXg725zIaP4GbFXdww8oRumdwmr71kWua10mCIPKfvrm8fdb3/b7/ 1/9+/fXf/vK3b3Qa/zTVxPlIBiFtlSsm7DUy/VXbbvT6k462u0L2OgdpGicHXzjkONXx0n2P 6XPGfK9+voyY5BAukrA7eKhPwnfbz6F8O2zEr3vCty6YNG8I5Yeppib+dwpTvNbPGj2EQvlh qqlJUEahpkpe2quL22Z81+97TX0DR1DMI+5mtDHy66Sow0sp3zZd+6MXLLA4HGrxreXRuxkv m7d8fNrJfo72kKdv2GBh779piuOZQmlTvzx2Tsy+Gd+N1g78A4Vi7tWqK/XAGYeWfN808OgF G+zCc5I9Z8wc3Z/y01Iz15imM0g8Pu20fbbuGfxpmplrUAbRybUMeGk5MVunf9u3v3rcDy+o +/pOxqEl3/XTzM7CURYHIy362R29dz2zowO/fvv84Nrv+g2lUCjTN208+lDMykrbN33GqP7q MnZe1ynjVeLzg4u141Io3/44foLrwydv2/hKCu/JpQt2v2jbjjEcbxWU7D7F8dQT3SIzQ62s 5g7RnccZNsHHHrbsjJV1wWtqv1H9G7tqtaCumCCehFrNmDNY24+h94MbCdcueZv/otO3oc2x G41nMPOa71rz4c1G1tnaTLyrnvE4nZ59kkP2f9Jwn8vMjN47pc/I/v/6v6+//ttf//YPnSoH zVixMviFzl2JmsL9s672a2YP1ykyLqtVv48vnrf9pQ9Vp7dfZq48K8/WrMSS/5o4v3re+CGU n00sPA/fSDuwum8f9ekZNNOi+bjd4wsM93kpr48uo1Kp1H///eu/fP2Xr//xb2qTeY6dvAU5 K/Kg9byRVB2d7urBXieTX6lUKnXAaOpUv1impDFYrxQ35OxfN23UUCqVSp0wUd8rliSLSZIU Jd7wWzled+gJy/W9Hn6g1s8b7jeQDzwdl42n9v7Xv//x9X/919f/+Hfv3uo6f5zU1zr2bbMb KKhI8sEZx2VzdSdyJ+1cdrMulZmxV+zHU6l9qNRfVx2Mv1PA5WYFrqVSh1Kp1FGrNwbcyeBm XVlLHT+UOmq1k4WNvf14ap++/X51uH4rITrWd+V4atOvrzSH1UCSDyJ2GOuOq+6q1RRVNtRl h6+ZPGeoutGAvv1mON7ghHl9hnC/gSRZCX5rVzReZ32o1F9XO22x8fBbvSnqTfNouKG+lhW+ xrKpSmrfb6kmwQF7Np0LDfRJbmqkDvc3hNRcXjtn3BAqlUqlDvtljs3BN6SsquW4t3wtVzS7 vvXMXaJTmloIb/n6rBhJ/WnKt1aXj1uNXTqOSp1obuQbW1dz2W3W2HFUKnXiCiPfFG2XnHsv Di/V7W7AL3PmHHrDlbf8dk37FC/eXNw2hUrt39jTxClGvtfr3r0It1w9e0jjY/2+o5oev5wm IElSyXp+aQ117BDNyAO/7T9n503ue4Omjwj3X5zetm22+px8S53g9N4FdetryXuu25aM06kq 5DItoPPhfk05/0H46T3mcw+/yVdUkyRJsu+mh237dmX4U7qsukVWKrx5YY+t4UyHMGXRg/3z DKzcdka9at4d/e2jQOM/6/u7Gkxb4bAu8B6naUPLcP/FqRM+u+c6XS6U6bz7WF/bUC6VPfKy sXDa1nXhfm119svkI8aTDjzgKYpJAq3K1AAAIABJREFUkiTlwhzavinUn/trzuDP3w/afIIt 1n4+t76GZJ7yWjlzRO9//usff/uv//5Hr94UzenuP1BvVwL/bavbtrDunPRfrL0gf1xou8Lj 6tVNegGPhI2Nm8L9kH3b9y4fQaVSqdRvqVQzl9hnrzt4qHJ62oXV1FGDqKPXulhu2GI3jtq3 /w8Tdt++mxgV42E6jtr0q6bK+nckI8xzxYwRus+ZBa5el9oYubaq7O6eKYa/NLb6duBAs5Mn rQzdfLwupbYoI++xugy14TNnWl24ZDXSLvhGelO/9STJuOG5wrT5wKtbdaUemEzabdM08LcD h5iF8a4c93Q3GU4d+OsP8wPviIjipnGjV1NHDtJ0OPD7wQuc74hyO3cvnfpqknHSw2z6cCqV SqV+98Mwsw8sqFtTSSbt3mjQNDvf/UA1P+VmZXDQx/vQ444OXEOSd05sNJhJpVKHzxpmG8+X Vwiue7iaDFeXYX6Kry2jppy8s0s7LpVKpVLHrDsemixp3W9dVSkjdPnyaYObihxENT8V4rou IixUt0jZ0+ioLWN1Oxwx29wunpQ3+y9bHUkyYt2WmwzXdtVqQV3+02jXzTo9TVnjeziRV5rm aTp6aFMRIwb9ZHdaqCggSZKU8Z6f8ZxMHfqddmSdrc0wbh31XaTteepaP88znzTcryNJ+jVX k2XDe/f65z++/vP//F/v3r2aRu83cNhEl/spDM33eJrCfee90ZE2k6nU75qKDHjSqt/KYnrI MhPNSaFSqVTqQo+Ea7k6jdKPB22cTv1h4o9GB+9LL/laL5iuHveHH5uP++X7/YT7nBfP79+g nT4UumfxkB8Wr3c9FEKj0Wg0Wsxl2t0cRv4HE+82yYQS5pPbly9epDWKijztZ7dk5bq9hy4+ 7ljAL+aJ069d3TlzltnWtXtjEh+/EWj+YBazWJnxtBOu5kOmWLsdP5uRyyHYAtYlP4M1u/cH BtK0Ap3XbbS2dwi4maP5UG0znzfcF/MKs5KuXIqhBWxabbR48twtB2i0c+pC4x7cf8HRtuQ+ Sj3vsW6x8QbPiOBwdYvTkafcbRcbrfOKufREu5qp6PWjR7cvH/Nys50+csc+J5OVy802Obsc oUWFh/mtnbvz1L1zd9LTznkFrxvbe9ioWZY+noHHA7ztzKdMWzDZZLPfkUCan4+rneFk98u8 Ai5BqBfFPbrBePO+yKZxabQz4bQ9q81NHfacSdS5bc2Tm6E77c1WrXWlnYlStzt82HvT0vEz fqH+eY7TJw33Oa+SI46sn2+xM+LISfXQIadP2K6e+GP/Ias2B9zM0rbMS4n222NpNn+ta8SZ xpk+FbTfdfXMGUP/rrfnemOR6nB/7qwJow1XbXQ5QKOdp9FoNG9XO1u7LUfOvdKG3az0+Iuu 81fv0oxLo0VF0Py2WK1Y53Dk6i0GoZQW8jNuJYRuXrlw+rDRBibb/COjzrtYLzJfMNV41cZt /lFR5/02LjZ38j57S5P4sp8/u3dD55qlHXa122i9zvLQPaG4jafsh4heZ6YkhHluXTvhH98Z ue0NvPbwZR5DwKQ/jrkUs93455Gz9aztQhOup9JlciVBEPw3T5/c0h350CGvjRYLLV2uirLb XDC3vXBfLhHlJV+Ou0KjBe/etX7l6Jnet9paUJeTfO6sm/US0+1eZ6Iimk6K25rZhlMH9/lx tV0nwn310b+6GOq2ffvWA+dfFcqUt8PWbnB0DTmZ2fJGY7L8t9mB86Yt3L4n7AFD8OTZ9e3T vl/oEfn4ab5uq+vHbbdtXLDxyL2Dy0b8uDEw6dYbgmgV7hcys25vGWi653zYA2HLamSCAkZ6 fHz6G17BR6060Ezb4T5BXD/u6eNoG5HW+GomYr5Mvn9V5wQG7/PZvn7Zql3Hn0kYhQRBEISU X0B/HH8x5uLh9WbmlgstPHVaX4lLepopIHRyNiY397zXEiNTSydX/xOadl5bTBeNHaG31Nb3 adPqrMnBkfbzvvlpzgQTx4NHw2g0Gi3syAnXzYYGrmFprzt0X//812mPz7gFrBn7zZBRc60O 7AsKPui52WzK9AWTTW0PHQui+e7dZbd09r7YAmk+QRBEZtq1Y64LrXdFnQtrKu/s6RP7bQzM 1vkcu/5M9w3IzOvHDu+0XG7vH3U+Wj07gd4bVkwdS/3PBS63nj7XafnopP3u7Vs2uwVpnoJe 9iYLRk4aPnTD8QJJU59SiSjv+c2Yaxe1A9P221iardsZfOO2zsDsB5ERrtbGZvb7os5HNI67 3Xre7GVTBw9ZuM3G9/LdZ3lCgigiiLdX9u1zddrirhmXRqMdPOCxYfUia9dYyZtOLGwq5Yvy Um/GXLhIo/msn79mxfsX1H15Le7wTmMz+33n1EXSwgK9d5lPGUP9z7mut2Oet7XLhxQUCl4+ iLlw+fA6U+st85dt8VuzZJrZzoDgUzSaj4+3q9X6C/8/e28d0Gay/f//Pr/7uXevrdzdLuxu 2+1ufeu6VdpS2wpuxd3dEwgEd3cPGoJDCO7uBA3uEggybZGWFpnvHyEhgbQU7navfPb812ae c2bOzPMkvGae866dnCYDAHoLckPsVET1bKKiMbQxhwX4IMQ4BAwDYwvbGXy2F4RZGUqJcSmi o9ZnEBvkZo0Q57hx+O+/oPPWOznaAzIs5DUQCBsvxoeopY6copKpSWwrg1bt5MQoqRYfm4zD Ym0UVGTEtwjqTgMw1FyUnuGooMJ1i/2CtFVUdGptf3dPV0dtfrSXg+bPfzj5WFndKia7hNgN wCwAJX5y5kikoQNDZG9La21FEVlTv7qp3vVfFcMD7ZlBik/FlBBo5wAsFovFhmOxdgaSwlwX Dp/n5P1ocH9yYoRUg49NxrnoCwqL8cgYYbExtG7Gp+fnN40wndwvt+H+7DDH2adSJraODJ00 cIiPY1wP9YnxnqY8SujoGLqzwCAfE5XHj+Xt8YS6IQAAoIyB9sKMVDMFMd47F+6ICIop2cQE YrBYrI25/rMnHBIo/HTHBymtfyz7L4T7C5Tn3RV4PB7vpyLyWOixiIkfnmbFTc0Du/qDc26g s64kB79hoY5Ghho66g6ZfRDu7ETgZHtzuJ6hsvg19TB8Ycfo3Ov1y5dfrT0n1RWGokXEZUX1 nUrbR+HaG9iQ6WJrrWXhyBA62s/RSlOaRy26ZHiGVf2b3/zk/mRbU0UePtrFy1ho3z5hpF94 NLWjWfn4utGN9xteT6/2RtqqSmkYOTuFUluk4fF+DoYqGrqOjlkbtGYJjI4Q89JSU9E8dxA6 sirG2kIS8toe+JgEfIiFhq2jh1sZGKlJzbPheXr30uknytpO8WmpbjrC3EK3+eW0LZzwMamp +qK3jTwT63ogXBfFtVW1snShxcXj8Xi8t7mVupa4YXgphDThv/GxrmhbnjuKRqGeYdRGsamp 5hqCIneP7r8l8FHh/uuV5S6CjTjC2M7Sh54cB3P5X66ffvSzSAADGn4xNVAYocrDJ21k74VZ b5qa4msiI3nn8AMJ/Y1ODiZGW0qcPXybl1fbOhwbg8fj8SGYABPpu5p+xWN9tKWzuvK2PkTO 2sqeFhePx+PxIfYOBhqyWs4x/fD5G7g4TiLleHkYcO377tJ9abRLQIy/I0qd9yoPL6+KTURA TIgTSl9ZzIjaGEII5ydnuyoY3OGxmABz6bsi6ISCFha06322NPtimJiXnGjB9f2NJ+ISZriC MtLo6spsf01Nkbu5EvetHzieeaZHFveMTC9ACJfmZkZq8LmZG5FTks01BESMPQtZl2b4ALg/ 29/YWIzHx4ckuQhfvGLgwkpQ9xWltzNcVUlC09g1MIw+KUgpJd6L5y49ubY7uA/h0mwrkeCi 8FA2oGy0f66jFuthKayPrB+b2HKmezLX1kpD7o4Kbmz1zWy/j4mkjLJ2SA4TjetsL/UU/LNg QFGgnrqggrptAG1TbRPc7wjXsEXqqeCmNvdmbRXO9bU3dbT1TO5cK5M13Iewo70uWPi8ZW7/ 1CyEEC4tPh9qL8BnE2gTGBeR5KIp9UzNNqGufpqhG9VF2ZGOLkjJgxxGQRgcrXUGIaOkmbzw YuOtqhUI69JcjTUl1JXRAfRlEeyC1nh69fIP53XSB9bL8Ey2zYfznr3Keeqxqp61Hx6Px6em 4H0QuopmVpiC5p0Mdenl9FBFQo7F44d3Lp3j1tBziUtKdNbkfyJ0W0BB38YFH5kYry94zcg3 ndgHIYTPlxbyAiQ0LJ18N76q8PhgWx09DQM999wBBinm50Otebb80rq27kFYanaSE50Qkrcv f/dA1CC8gKEPI9UpURbSArqeUbgkPB6Px0eGBxirPr54+K9PDXFlNE35NQhfjrVVVWYzBbbV 01DQ98ANwJe0VfZqoqs9TE1OTBPpHoRZj+tsLCEie//SzccinDqRGSVd5MU3byAE7bnZvvqC ep7R63HxeHxMUgJKlUcI4VNW2L+TPK73cQW+7GurKszG4yM8rXVvfS7k9w5BXTAwn2ujLKWL 9AimPhlTkxN9jMX5L317W8wIXcDqkvfZKoQTvfVlRZF2Tubyh/htPJWEZWW1DW398fiIxEQj SfHQ5PLBGQjhInmhFWMma2hFi0s1DxMlFR2UGZZxjw2QO7NCVPifSiNd/CKozVKSEnyMxUVv /vhQznyjk+3JMV7WkgauDP4iMX5mmoLP1AJqGbRqVyF8OdpaWZmNx0d4xujeZhfy3yKouzAz 1NoQ5xmjeY3tKL+MpXdCDamLPP92uq0yN9NF5vrjB3fva2Myshr7F5deQThcGY21kZK3xscm 0CLjMAlOmmLCavbJjcR1gYwVCIdKgs1M1DVVLQJp7YI8rXRk7964efK7n3QyPg7cXx9vRXZE gIPxs6Oc2pioMFr49Iys/NZJyhz92fgawlRHMZ5fDt3mkza0xuMTaZ000LJwr4Qv6HvNs33P c2yFVS1c/SNpzlLweG8bLXkNY2+fApp8yUxPd324h7Pi9ROcwo+fKpt4uYfj8fhwHFab7/J9 XffSkoGPMOJ/S/vPgftUG6zpTtX/+YK+Z3ptx68df3pioCtDQ+yOtJoVrmSnF1OGQLW5prab I6aiHwyPDxdgbSw8I/ILm0YA6B7ojNH8WcmPUNEIwHB7aa6/soqCX2xFByPf6S/Fxtjpm6Jd vGrBOItSA78C3KeMD9fEWLvbsJTARFvY+CcRx/s24b0GXzsdfSGFwArWk9JPTPHw1JQW0fSJ radfSyYP12R4qipLalr4pFcws9e2XJz70713nz4TVEM54ArK+8E0ebiT4JFY2FLZDUBbbrs7 98HbkoahlZXdww0EL9NrX5564uFf0tENGopxbkonpf36hjsAGCYmp/mbqGr6xDUw9JkyBqoi A0x1DJ3CgmmB+8sc3Mw0FPVDsDWA9tp+Z1t1lLuqwO1vP3lg8FHhPqky0V7n8mmZyL6q9Q2R odGB3Eg0ysI6HFfIoBfdFBVoqyemaGGLrRmnIS5yd0N1BFL5zrd8FngmuM/5y10+hF18eff6 HlJTWQDSSklDJrp7hHpquKu8ONpRRV03oGC0k85yp8ZBJyHaw1AP7esWRzszXu9jrSV1X8DE L7ubTJkptOUSf3zvgUZQdvcUZaYzUkUQZeERTHzn8Doz3RzUBU7y+dYOk9cnYahtIC/QCo1i vchcAgNyuydolGqwIiFR89J+Hq+oss71U/OT/aDaVIJTWN40MoMltadFrktzMLl78qZVXWEr KyL94TX32xMTnPWv3bHJZAH3mzL9rZEymtp+2USa3O54V31NpAmK/+T3Z6SVdwv3AehrSHB2 1ZAVUrZ2cOSXkHBwia5u3dxmcLA9xeXeKS7d4JCiHgAG+1oSkGf3CqNiYqoZ3zFI9dXQVuY3 De0rTkbcERGxscXWtm6B+8OkRozgfi2fzKTmXfb4HcYa7hPxxghdYx2brO531c4eqs8PQEhf uyAdO1q3aVPjA2ruj3cVlEUq8PMZIv0LS1o2skFM9bESeyQmwQT3g3WffnlFWsevsKl7FAAA xjt7CkONb3PoR5Vm7/T0fhOh3pl7300pk8j62t6hmiQn4+vf/PTEJ7SquxfU5mGcVC4pBoyS uwHoLA0PtzfSMowrnpyi929qrL8T7+Kqp4r2T0lk2Fgo9lEzluUS9OsmU6gEc6izloC1RSGM gtKauxn7mKJ/TV4TiUyk3xu9dRnhwZbWVo5xJZSpd0oYT42CTrwl71VpPTfvio1sEbwtEHLa eoG5LZTpyfW4CRgEP8+xr0/J+Ptld9OuJXiY6qFdIpOrGO/JjqZSjJehhqxBcl7L4G7VkwEA oMhL2Uz13XC/yMvfSPaQsH/T5BS1Htx4R00l1hZpbOSNb2H1FsSHWa27qYrAteu88qrWhkEl rb1jAJCaavKxQbntUzOToK8e5+1laqYflNs6NUOvQ0ce7K4IQxpqGrhF51bT99iIYV5oHQlV W0bZ2/GO6tJgA9nre3htCnC1AICBIRIhXEFW0y0pjanTvbXpGE8kSgcRUDY1zeKNgEIPXzPV LXCfZqTYKEuFa5dV/VunetZ7OdBZF2N04mtBdHxc7Si106Ay3MJQwzoQn8e4nTVUW433tETq ytiVETvHAABgoKo5Bc3LLW0alF/WRp1SCgAdBWHORjznb959/O9Sc7/UlvsPR59KWHnl17fR O+kirqbnbB5F33RpLAp2tDO2NUlgPH0/NtJTnuZkrKNiHZxexrA/k+iu9eTe8TvcSsHJbTND kwAAUmOKnaPIw2t27dVdO9y6/lXtvxDu063Tz1zNVM08peMjdOF5R1QQUunBPdtcCHdcYX40 JTXMRcowiwzhW9hbT4iMCEpIqJuGcA3Cqihzewd0dBWEa2urvbm2nhauntF1jBLAC6OtzfGO 5krKLoVDbSyo/K8D98fq0vGBW/UvqeYVW0TafExtqqYl3vT4cVRyB5nVpCy8HK0qQPErqtl5 Edo7169dg3CKVBDgbqytrBtQRIZzDMRydWU5U/e2Mt8DHgUEwieugAzn3sLnpPz6iqKcHghX V2CmrpaiJJ9JTE7Pm9XlkRiZk7yPlLWC6nrgi5XlbKvbCq4xBXUQvnkxMlaAMjdyC84gdTL2 eaSmNsbFDGllXkQmz72FEC6MllRiNfgFLfzzJmgawIurK01ZvkjFG0fv835UuL+w/KbGi/uS pmUMdn29rkLYXZMa5msX4MuoFz3T1JVlL8CvYuRfSOxf7yVVQddP466kqjET3EfLXD4rquJT SJyeW4QQwumpztQYwduyftWFfYsQQrgwvdyMs0bqucdVMh33fN7enOvvYGWu6t02Rj0zTqki 4nR/OiFkEdVAGl8cLgzxkTjBfgeFqZkYX3xOTPBxlnxmToST7wDYC+Ot9c63Lj62CsgkrU/C 6grsyU4L92S5wqxtbL0IpE7y4nrbt0vdnlxissbaIfUbq2skMcpS9f5dBJYMn7+zcsrC8lJ9 pNRFMb1Aj2JWJys/vOb+/OBStemTu6aeLOD+9FhHhrugoIZ9fBZNbndtZZlSFR2N5Hl46+m5 3cJ9COefD5ZlIwXk1Z3MbDWMEQhtk7y2zfoiqxB2Z9soqsvqacT3QbgKYVe84TNVKR1UHqNW bWd7qafgX4QDSI2EOKSNqoaseWE7hEtb4H6lu4qjualz7W66+25jDfenu9JTfJTvieLqR1+w zs8SeN1HMH9wRsk+KX7TDH1Azf3V5ddT1WhbhJGWZWJSw8bameqsxNurCJ49b5DBCPf5jlzn 5zeJyW4cp14MKZU4hKqJpW/oTqn020WYrqYsKyVskVDQt7S00B0uevDpYw3DcGIfnH01l476 WcY9qbQRwnlKVwNW3Ug7NLGOSQMZtGZn+ZpbW7r4kSCgbSBPthWHC/79iV15fhc1W0vLbwYr I129bQOjc4iMfexIdXGSvfHAjzwMqOWX5mdH6nI8LewtIzJamcWWNxlozfXQUeLi0yqElPX7 b2qkNc1NSFjdMSm3e+LletyBighjw6dnObjVpENpL3KA9rIEX0uUfWDxxPNFetmn+Tev6tI9 DFGo8Ijs3t2qJ0MI4URzfrjw5xJB74D7E83PMYKHntgHFnZTv5RX3y5NVoRHeNt6xuTuZl9h 3W1JZaT6iVOcUpJGRp6ZeU1kCOfeLDXhw4uaeyZfwvnZvopsMw1d97S8nknGHwND5fEYBzMz B0zZJHxFTcZUXXOqrZCwJiK4jC57u/r29WRFuIfSTQktK3QBpB7Grwx0dLINcGPq9PzMcG2m O1pXwy2loYfFHim5aTZc+EeJoC1wH0II4VzP83LjuydFUJGVxPVeLkPYFastoCxnZFFAm5bh yiyMI9LaI6kdztP3lJZmXg9khjvrGDilpFRMQAjh8mvYFeZsqq9jE5W6IYg9O1BHwBhKcJ/+ 4pQO4d+l5j4/L98NBaPI4vb1TbLZgSLfABPlp3Ydk+t70RRyOyFaQ0sTU9E4Qn+SrEI42ZKB 8TKzt/FM6djYYGtrLDDj+fZ7jifW3lm9fS8hhHOvX5SlKd2QQsUHV859vAH/W9n/ZbhPoUx0 N2Qn4RNwNIvA4fREzgupIsMIO/ZGBiDRWhpp75xYSWnuqUbzfv3p4TsINLZ+jNzQXWb98DY6 IquxH5CbsyMdfjkubBHsHobbbE5aNgbKj9w7B8a2Qo5fAe5PDPfm2AkrCT9kZTx8IroepcOb 6w1sA/cr4uyM9ES3yu1OAdCE1RJEmLh6MSu/tuViXZ7uPcXvHFpGYqGI3Jbb4Sd60Sgzs34I ANCWG+kptJffp7ekAwBAqkoOMr4h7T8w3AFAEw7tovrwrgEOE7UljR6qGjpoDaeiYTAzA4bz bUXNrdwcCjZFGh3sINjf+kLM7GOf3I/0VBRUtwn3w6z3Li4xBV/V2z/KtIHTG66CtrTVjtoi ID3a1xSq5pVYnU0tfkOF+yKm5r65TE1LAxJd9TisKqg1i8j5XhgTkZMSzmGR2C3ZMVNXR6rp Ybuo9KTex9rKQdkyk+qm3ltMU99YmYbz04zFbB0Z4X5ve01BFqMzPxOEksTZW9aEwfF1Mt5T 3RljKMDzhOUi45Uz0I9qoe9egJ6y1nC1M6f4UbEV1SMAAAploLYeffuBoBkivJIJyg+1dVQy RQ51RpgInT2hk5HTyOpc5a8C93sxzihLFZ3olk0v04x2gXjZBw/UNXYP9wHoKy70N3h29tyx 61cVfYtzt6B9MF7bloO89fVtg+DikkEAABjvacpSP3hH0toukchwm1Lhvg2WMkwhhug/4JFD eoeTxrbA/WaM4FmzyNxMajqmJ8FQfWlmahJDSlNLWlr7d3p2v5lU5yz46XUFc2dXBlc26kLq Jk5emRu5J3c3NhSmMM6gt4Wmyr1DXH4jlZuqaG0P98mkvLBQJU7xyLGaLWy3MSU8PtArppVW LqbYB2OtfkY7jVE9gtxDLEWcVvEsfF8hNJbWRCD6SJ02yC1sGgEANBEC3Z4d4fEfqeoGALSV Yv2Q9xQDx8jdYDTHTQ8hyiXlgouO3XILmvKpIN0Q8RugvDHFyctEVgGNi6Hfr6nZ6ZVdW0uC lAYoopHGBo4M3gilJcTN+2DTE2NDdRmZqfHMYY+LadnZ5dAa9YTYISw0DGNbmUDqSH9zsuvd L28o+a7D/bFOkKXxVEBdzchty0hCgnwtBK9J+mTXN+38pQ+6bQP3G5ISvUyeKKCjGbKTSqhs m56ZZNX8Q63W3VT66X1eQ49CwAqbl0YYaqjyyBjjcFufoW4KPFrW/t5l1FdOQE+wtLGFizFu czW4yUFSY6CCW1JjQTsAk3VNhTb39vMbO/gEbXHoZWamyydk3UIhbR3S++E+qC+MNFe9co8v qLmudxIAMDlUWhqvffW7R5bRNbVDAAAw3Ucc8rx3X8pYw5pFZG9v3StXrPGVHaMAjFXgsq34 LprXVpA2/8oo91c3kPt4J/fp9mFwv9yN+7NnXgUNTI/fWjcEykmPXjNwJMpBQ02cV88Vh9t6 CyK5uEy8Izf2yECiu6qgKJeeXRHYeH2iMaXGW/aYfmF5266EwX8l+x3uf5jNT3TV1+YRGMzN WkOJ56LBro69Nxfg/HQFXEohnJtPcpe5efHY44dW5S/W1lYoUQ4mjqZ22SNweW0VJKne19Uz RmEImy02ON3wGp9DGb5l6/T9OnC/K8PLU+vpO0zOIrq8etO53m3g/vhQC1brOKdL7la5XUpr qqezuJBOGRxlOA+8urKcqXtNRFhZN6yGRQ2G1RWYqWviHGaJH6Y1PqtrGxZYByFcWFmu9+ZV 8U0qqIPw5WBjkdZ+fn1/25AtaYxxDbRTv6GQ2Tj88g1cHCoMjdQXkUmHw0yocA3CkQwrIV35 j35yP91a2crSxZlhuvNqu7qZefk8MbHQWfKKU18PZfMbI5SKiKwUHIZ2KBcOJka7WvDKRTG9 XDLV+SZagNsqK6VxBkK4PNE+7f+AU87a1DN2S3YCAwJMbt50r+qbXoAQUqqIaTanhHDdQ88h hJSqaJwp1ylzIrV7XYSoEE1GuD8/P9tdRyBk050lYlJcRS5fM3BOaVxnMavLsC7IHSHLcoVx 8fDJe5dX99FYyepbWOdqKCMnicTkT0EI1yCcI6eg7NSU7htmMQ1waW5lpK4kfyNyelqKv9Jl bk0XGwIrCvSrwP35huY8Z45rzqX905vpTmOgr6Ha1d3DfQhfUd6Qwiy5H9y6fo0X4cWiGNjq WziJsRATl1H2SaLt0HSEqyOUJHkcql5ASKuUTYX7IgGkkYHJ8jR7A9GHirbdL6aXVrbAfUNv e7tgeuWdxfERUnUBw8rIKScSh3d6dp8K92VkeXVsGFyFuqJNtBS0sf0TtMP2y4vPZ0lFBTmZ 9DZpyQnmT/dJorFhjcwut4f7y8uvySUmD1G+hJi2zZ89H+ouctTGEicHqHM22TYfKXRWJSq+ kul5MxCn7+vmiMrf6XAXYbolOlxtAAAgAElEQVSavlMk9Z2kt4sv09WOaDlgwxshhHOv56vc fpH3I5Q2wqXx5jzfR4dkbEN9cFtuQX+Ur4nCPe/x4dllWp+JeTb3NCwj/SJpbTIyCdX9Y7OL m+KPVONirSXkrAmxibSWucXZjeMLW3RGFsfb26tzmcPKqwtxisVDMjUzc7X1Wc6ct9wqRgDD 8l6FcCjbSlBOXHED7neE+1vr3n1mu2UkeALBz0hez8otoXrnL33QbRu4Dwbmcm1E1S1d/Dey QyBUt43P/lMFUyZKKkOVTx3kQMSPkihbPx7uKgvVOnrHIDxq6xd1lIOJjbaaZu7LqcVVCOFc TWSmswKnx8Dolt3IiZLA9NSUmGYIV1/DOayVnIaKvFXQFocpCQlmjx7ZJBaWbh3S++E+nF18 nmF/+7qsWSy2+QWEcHXl1Vyfh6GIlJpBRD6t0NhirpUzUvW+DovIBAJKVtbG2b9sGsLVVy8n gvm1HGN9SzZv1lBaC2Klv7tq/JFO7tPtg+G+mAHaIr6K6dLisnj7K1JJ49QKR68b6zLsHh+T coiMi9sybF8EwlRV15cMX67fN22NeZaCe6/oJoy30n8CvX4OUxU1HWI88lgXbPvvs/+zcH96 arKTVB1qdOOHs/u+Zlu3r9nYPv/bn67x7wbuUwCoDlbQcnAJS+2pbIuRucj+xWffcsvaJ1c3 5Ta78+8TDUos7QSgozrFVvngH/d8tedLelhGO8l5Wj2hd3grKflty/LQbRu4jw+ys9N5x6cN vpI29q4WzP1oy032E71hlNlXz7KSwwfD/bJAPfUrn/z5c7avWabxGBe3XmQNmJwCZb6SvPpG bkHEzaFGu5sjfgtBXVJvm6fSsR+P07r27Y8/nVaJjC/uYKSNaQhOXUMzGmN/t9Fr7kcy75kw w31SkrUV3/d//PuXe1gmh+36fSnnRAAmwYfD/RkAyCP90Z6a3Nf+weDpqy8+Zz+975Y1ng73 d2aDA+3xllc+F0DEY8qnwExvHzFC//SXohZpWIZS/2ByZDjTw1fx2udsbPQB7fny8z3f7Duo QfiIcD/VSEvHiNcqa/MlE32gdLeCuozWktniK3HWMCeXyGII00RCpfWjvx9VsozLq6BqQTaU dXpwXbkpq+ieXreBQWlwHwAKAJmWj2TkVFR8Kztb68KY4H4TRvCkCSY3g7opNNEPKm0UOc8d YWNj2/PlV5//9X//969HZfyC8nu29uS91kyqsxX89PP9X3z5JcO6OKMQGMLgamp8sCbC1Jj7 0JdMa+cz9n2HHvnsAu63lcU66t/g1M8ea9pSZGizFfvEuhjcs6tilK/++HC/Lt5chGv/X//+ JRvrW/CmgoJHIYPfjsokO63zbN+x05b3Cc5ziiFNpMHxzTC1McVBXvQkQxp/Fhe1SuoZGJuk CerOUCYGiUWpOheunNi7hyHmF3/94zkxBrifrKeqhRDe+DctOd0NJcYnH+kHr8P9oTYQxn/l p31//5xx9ui2l43tslJwecGuT9BvC/cBGKhIwGme3/stPTsnT15UdmnpII5TdlnxHwBQ625q 5qhtv3n4NEv2Un546c9//5zl9LGxHec3QeHWj8En61zWRDo45r43XF9xPUb2+Cefsn351R5W Dn88c0MUM9nQt+XCbeA+GCiLidDh+OSBZ3p19xSY7i7ABCpf+ZsAJrdu3dd4Z22J4fFTP379 2T9YRj7IxiZqU9TYCEBjqreL2AmuwMmt70O0xn7Umvt0+zC4T625X9rK9LTaBPdrXBH8l/f/ lfWqZWNju6Xq611MvzjRHWGN1I+qZpQX/h3u79p+U7i/BuHbBVCFNRHmOfI1+4Z9+Y/Pfjq2 S7g/2pAQ5ihqEPEWTja5IQUvfPPlhTO87pVvVp+n66ga2WuGECFcWF2t9+E/cWXv518whqXb N9+yC3jGlA5ucf7bluWh2zZwv7unJYTvOCqT1adT1dh0GyGBWMhYM2l1ZTlTl9c5NAHPklR8 MNyf7qqO4vn/juz96h97WKXxwLnvbjmm9EzOwqFqrKPpUxGzRjixhcJWe/82NfcLwnT5ORl6 d1wAhY5rY9Sq7c708Za/IoSDg9uSE2rNfUQu038yw/35IWIN4uixA2xffMXGKjvH9+5X9Okc HYI7gvtvXi801GWZ8HzO/iPdK9vX7F999skhZSs63N9xcrpTUbxq0pp6hCW4tgqXm7D63MrS eubFDK2WX78ZrB3y4rl0+kfG2d7z6ScH+G0+ItzvTC/3UvhEGEca2YLcBhN2X3N/Y1xLkKBp 6BRhl8FiCGvLr18nK4vyyvIjoyvoWpDpVlYK4mef+Va/hYvrMsYMcB/C3lx/N4VrFwyL28YW Stw2wX19TzubAPpzcxgfbylygZrKrz7961/+9h2Hgkp039aevNeocP/Oxb9+9g+GqTn2WF2d wdXKm8WptkK81unTR/cyrEi2L/76h2tau4D7c0sLle6P7ph6EzLfVaV9w9t6zX1CM9Pj8CPD /cn+2mCDI/+7l20P61vwBMdhNXzfBB2qzy8tVAeKXuQ4TGuw9/uvntphstqezy8xY/upwYZI y2vsx/fTknjs2veSmFrS+PzSuiI0Vdm1CaOj/fgw0/3yxac/nGOA+6SUQg+lT8Xie8mbt64G cHqWpgYbcL/c1Unywp/+9g921nb2iZYfdtcn6LeF+xCuvJ7rChAR4ThEzw77V0+1wnPKni8s bhFP/+CoJZWJdpfEE0YmWO5LtDfno57+z5+/2fM1yy/qHy8/fuzePg6WIITtSQ7uyvckEyFr T1RbXoRtLloPzu7/lPVXFjs7+yMzQsKWzart4D5cfvWi0+vRLxJII0zdElx9uzjdYHPrgawl KnbDVz9WS+vB/r989s7IMvaJ5RAuzc2mKR3QcEqMbtoc5WXPR625T7cPhvuaDi5uzCXZNsF9 clGZr/iRP/7966/ZWN6CpzhFNQlwZn37rK2xLFD8ml3R+PON4f0O9/+V9pvC/a6GLHcjjsMX lcKiM2tJ69ZIInlp35bS2Q3cnwWAUu2J9A8Ic0tOTzE48/UjznNsF2SU3D0T0zJNbvJ6tBW0 TQPQUZ3ipnvhkgqmYiMso3X1dA2SWWm4/Q73N8N9tMx9IR9SXROrNHb29g2NU8Dk7L8e7k9P T40OdHZ20rrWUFHoI3bwqijKMW4DYP/qcN9Zm++KYVptYyur7HT39I+QqRTjQ+H+KAA4a76f BYSQyGgGT8XBgWj1y4wn93dmM+Q+Yp7+qZ/FLKyxdWCwqj1B/+rnD43jS8oYX2zIsjYVFLgl YOJLIrXQIlenBQapXD6ll/nfCvfbczAuv/z5z5/87bMv97BRtSDZvv7miz//6U8H72r6R26c 9GeC+xPDMe7q4uJPDKzxdYH8jHC/HiP4hbwjHkutST07AygjAz1dnSQSqTo1z1/5xDFlF3xN y7vw6jutmVTnJvjpI9MIPIHxMTYwxgjTicFKCvyCj1Q88CRSG61NfpSzJd8h7t2c3P+PgPvK WkJyiHRSSzurW7BnYGCU8ZD2NIU8MthF6qB9XpUW7Kt0c/91VHBZGzNonSKPDPR3bXgqCkEa i3NdEvEsJFOohVQGKpNi9e58d1bVPim/nCFmqPJFZcPdwv1nKKRfBquRdJBI3QNjlB0vHAbb Fu7PUMjkwa6Ojeyk5norXt53XTOkvOifKcuzDdxXleczDWBYsYzW2Tc0TF7v7ofC/Wjd44eV XZMKylk67OruH59lAfC3g/sz3QWVAUpH/iZol1tHBKQyLEr31qn7HkPV3evtqXD/nqqbU2wF y8gkUv/I5NTUfx/cl9d4puRFYDVmEonUMzDKcAv+Dvd/VftN4f4ihK0Y+WsCkghEeN34hmXE OpmI7xLuL09UZmTZGaBbYanXMxGZWwdOcQieFrNpWS1zF0J7Yr0r3tDg/n19dACGMSyjTc8t LG0lFr/D/c1wP5r/D2IOeXFVLJM4MU55+ertyuq/Hu6vQfh64fk0haFzmS6K8mLCXBsiub8+ 3K81OcGpgwnNaWeVHPL4+Ozc2+VluCO435Afqi51+Y6g/3h9J81TT90gQev+bYTbLuH+GoRv e7B6BsrSd9AlcHUZdgegeKWkNfzTGSvU9OXXOkntZxeyKKmvpkUeHR4str4vaeT+3wr3l5cW 8w3O3Tr41798+iVdW/LbPZ999rdvD1yWc2iDNBljJri//Lq5IcucZ89tNGEwGL0J7ktbGeuZ F9IDvFp8MTM5Pj4+OjRebKkqqqWCTmpY2CkrpcJ9NW1lNxzjCpsCgMHVVG1cjP7jfVeMMTVt JFqb4f6eCNlDKrb/rXA/yuTMaZ2omgLSOAuboJDBhqoxhKtrq0vzM5MU8vrnI4O9RfY8fHzq Wr6bCs+sLL9ZeDE5Tms43l2Tnap/9dx9lHcBiVqWZ2VpoStQVJhbRtoKW84QsyTM3Fpmt3Df VOeGbjzLR+34+MQUmN/xwmGwbeH+2trq2/mZmY3sDIwX2erw8olr++N2XQ99e7jvKvSFgEtV cy3LZ+jk1NTc25XVNbgjuC+up4HGVrwjj1MvXi1uLUS2Hdxfe7v4tt5G7YGsIiq2As69elHu /Xi/BDI2rG7DVz9Wy8xQU9T9nZFnXy4u/ffB/TDjCxeMccTODta34Ax4BWm34O9wH8L/u3C/ Py870vIRDwKb3947Qo82BkAk6qG8wW7gPgAAjMaburpYCupZWt77/iYqUePJLWkZWSE9e7tH 19Xieqv6AQDkzmJsiMzPD+wK85p39Bfjvyfcr8DZGemJGvi1bC3L0/yOsjy/DtwfynQNQEqe M8jrH31PPdwZAIbybViX5Rn6LcrysLCpif6OEiOZ+0rGDon03JS7CMopqkl5Vr3vSvChcJ9c Ex5lq3ZNwL90mDz+focfCPfJvSBbU14NZepXwHS2lJSU4Kx/9ZZ1xi7hPpiZHBiqM5d7IKSG iIhMjo9Qv3CK3xdb3sXIbMsd5M2NUKi4xk4G4jNQkZCgf/W0/seE+71hTiiLd5fl0di1oO66 vQfu9xVnuBtxnbivFhbuj2UyN6UHvLL6qsH0EvdMcB+A3pIAA30x4UtqgT5cf6HD/an+VpLD rV80vF1Tt4jI9pc34/TPntIPzG/aJlcs7F2CunSjAECMUpVHopx9q0jDDOysOSPYXeQQj/9u yvI0pPlaPTl2266itH2bBf4vgvujVaEISw3ZZ0GtE+9gsu+3yaGG2hRroRO3UTFlZYPvazne lZPopid6W8yhaoJEBgD01iYH2/IIayaWlQ8yKSSn6F/TQnxQWR43xrI8lD5Aspe5p47ywO9Y vPbDbFu4v9kmh/qrEr0Ff+JFYSPfn5332DZwvyfNVtVYQcW0EGz7ckCJ7WNxRT2VgPemZ7Kt vdhP6vgtdGzlzrq8HdwHk4NdJXHIq3sFrKJxOP9Ic/mr9zQCm6d6aeR6erhtKF6KW9DCLqp8 c+UgZhuriM2y4r2I/rcvy/MhcH8kK0BPVVPRIrQNsDgssdl+h/u/qv2WcP81Bfb5KMmZuIQU 0iuAQwghrMkNspHbJdyHS6TsBn/lOz4lNnxnJbXQYmpmqCfn7ngX2/DdN3OLi+uBEC6vrYIy Cx5tC1+34i3Klu+zf0+4v16WxzWPVVmeNC8XCSGd0q1leX4FuP9mvG3I+dot3djYyvdLuS4O FoZGUMvyMPVwDcKRzI9eloe1gYG4ELSO8BNnuurvWCkmRPP2fq1S0th25S0+AO4vz/ZO4+We CjsHZndss8g+HO53RuK8TYSN4urG4AaBmh9aqjblumfqvku4DyGEi+PJEbZqvPeNoruX8h2e yMghkGENjHUyxopwOH0RMe/6+ulF+nNt9e0SyZNLwdTzY5flufnusjy7FtRdt/fA/VeUpXaM +tXHSqZ27ngmi3I0NJLkOo0q652kJoMJ7kM4TyFlRoqcuqYbh5B6wAj3ZzMsnM0M+Ny3cLvV N7Dd3VDeVNchs3vzZ9vauwR1GW2yKSHQRVoFWdLVt7BEr/j99tU8QeOYlsNuyvK8fTUeJ3tW BuHtV/6+7woI/1Vwf2mmszBZ4Ry/S2lh924K1qytvJnri3dWkNEz8U99L1pcXhifaPBTv81l HlZYMQ0hfPVmoS1KQtTcOzqxl0khuSPVxUNpc1meO7fcKkcA4xMawuGcTWV5ZtOj7VDigp4V /8xqf7dtC/c329oKfNlb4Cinq2eq//7svC/q++H+3FBdsiPnce2UoQYWRXuYbDjP11fzl+OG FUPT707P6hv4stBXVRmJCtpZl7eD+3B1Bb7sjTMUUVEzNE8oeZ5pcOe6qBm2upnh7llo8PU0 Q4oapg3QVV5Yenr1YiKI751leWT+ncrybAv3X/e0ZvsoXuZ1q5rs2/4W/B3uQ/h/F+53pKZ5 6l++YZnZO7LO1YZJwwV+NhbCtw49ld0t3AdNfl72qhzXuXmPXNdO7010klGTvnv4tpjgFUnP ygHSBAAAkHuqqmK0nwnJI30yCpnPnXZXpieFedrF1o5ObFXU/feE+32Nye4eeuoSVjl1o5MM urb9NTFaWnIaaG98OXNl/V8L7oPOsrxQa34hSaOA/MZOpjT2l8ViQzH+CRVUMc++Ens3MyMN k4ScbjqmGe4h4qNQQvf2fvJwq6DuMJGYg3FEIk2RSJ/Uxuqd1ilhtK6K6uwEB1ztGMOETpP7 ujI1RJ5qIt3TW2j/2VfibaMrLSiDCsjpntiASWTycH2ml4VjYGoWtR8fBvfBcENFnLu2gKi8 fXxWaz+T1mUTITU0zCs8p44KrD8Q7o90gXARLllb08gNSc3+0pgYexkRLq6fblmn7xbuAzAJ QJW3OKeUvLKoPkrr8kkuz9qyTqayVGnGXDpGZtaZG5Ebc2L8dUREOX86pv0xa+4DYoafNVLZ 0DC+bkMnYKitn+BqKXz6wD8lqAsAeB/cHy7x99ETPclpkzs6sUmqtC/FUF1Mllc9bH0GN8N9 MFQfH26veOPyXa5j//vUbB3ug4lhUBlupC6vbR2YVMlcor2zoDFQ7vuTuj4fBe5PAFDqJcKl j/LBbGwrEMuSQ6wkeLivHHrqywruq6sIK3rl9QAqSBxuyMoMc7ayD0pppQxMAgDAYHNGiisP xy0Z28g65lPGxNLk4ADXoOC8nnUK+a+B+2CoPi7aRV1IwsAxuZU0yFRJnYj3Cw6LiqJrm/YV ZyWlYVOqehjB4mBNS6LZnRNcVglVNdQVMDUGOglRYWmZZW1McLiDkOys+5hTybdponuS2g1H /VsPDYrIzetLZ3CoJyfCHCV3fT+XCgPcB43pXhYIVQQyoZ4Ojgdb8tOcBPmO7zlNF9QFEwBU puip6CiZmETn1zNS1/HO/uoEdzNXXElH2z+hqPteuN9Xn5mYFpua18OIaAf6muKdbv8kapWE q91t4G3gPiAVefmjJcXkXUNKpno36O4UAJ1Fke4hESmpNEXd3kJXMw3JZ0pWIfk9DG/djY/2 VaW7ouyCCPn1fQCMj3YVpRlwyyua2cWUVzNPYVNZXJida1jZdO9WjLwt3AeA3FlbYfjTdSG0 tryIkQLfZRVcy9T0xpqjjICONBdVORUde7fU6l7GZTbQ1JUdhjINy2jv6wMA9Fc2J5vz8Mi5 JDQxbuI2pnpbil64dW+roC4ZgMpUbydHJNLCPTQ0v3dmdnuO/l6rxSKUNMTUTPJ7p6muhuqq 00OcbZyd00hdQ9QxfRjcB721MbaO6vLSiLBU0szwxs8XMgCVKV6OYdjCgg1F3d/h/q9qvyXc XxiFjab8j0zd4+s2BEd7cwmRRtLcApy7hftwpqYz2/gGvzLXgYtqdvFhybgEvUt7+JQfnBWy DsqteQ4hhGtrq1M13i4obQ3zkIQ6poG+mh1vjbP2iitr7N8a/N8T7i+8GKnKQ/IpmcYl1Y8z orixuugwW20VHb8CFoK6vwLch4vTK00xeqoKOvZRmQ1Mf3svjLY2Z4TZ+Be1Tc8tQrgwWlwR o8Mv4h/fMD2+vo/zZnV1rBaH1n5w7MFWQd03L1bHCnA+ro5WVt7RWfk7rVPCaIszKy3xgWn1 xAEmIPK8I9Ifrc0t4t9Kg2ULI1Ul4bq3bj2zjW1g2G1ag3CqowAXExYdSu/HB8B9+Ob58kiO p7qitqlvWGk308TN9IyUxNnYJlRQXgC4E7hf5RVkaXgPmUMXAV4YaWlKsEIr3z56Qcfhn4D7 EI5URlno3rsuEJFjwHFOxigwpI6J6nYRgrwUHojETgyvl7ReeE4m5nmhjbmO3lJw/IhwH06P kQiuAsLawYXV9FcqVldgd1aq9bNHd7j+CUFdCOH74P4bSsdAuMDPNwzc8E2bwNJ8R3q6nfh3 5ywJvZTnEG6B+3AJDAxkIUR4xZ6e/V5AZgPuw+Gq9EBrOXVEYMkE47F6uLIEK8xVJfSVPxbc HyjH2JjySVq1w6n1SlTTU0PFMeYouZ/38JuwgvvRRmfOa8fWTFDftlkCY8N5vl7OvnFl3T0v IYRw5e2rrgxNHXlZTcvEIqaT7dOUwSKcrX1ARmc39eJ/DdyHS6C/PxOhLKtuHphX0cu0rzjV WVUU5+eYTFovzDU/PNZSGBRc2vN8cWMtrSzB7ghLeSUN8/AN+WTQTiwtjE8jTkC4MX/zIwu1 LmK3RS1jyhqoQqDzFa4PbpsGZGatC+yuQNhVlRRmLfZQ4BED3IeU4ZY0FyFRrdCS+uHn603f vurKMDcXPMfBrboB9+FwR4qfp5SyhFNKyezcc3ro1beQUpUbE4VLqyT+E4q674X787MjzYVB IYU9LygM2YGwKwMtq6+JRufvNvA2cB/OTTTXRAjJSaNc4tpbmHaQwVBjdnp4aGjZ5ItXyxDC +cGSnCDtu/elHZNa+zZ6uQohpS07KhKDiyoeWJdyjbF00tXVckrbEOOFEMK5pVcNGd6ucTmk lq1b1dvCfQghhENYbaSy3F1Jazzy/HFhn4jKIaY1N9tShHE0lNfWDS3rePlqI5HLS7CLkBAa F1fYMgAhXH4NO0OcUIam7mklDK9EUEjlaXbSfGdYCuoOkcqTMFZW1vZO3lndfVPMouA7tonu MgzywhW1BCKR6mpp5tVATqSbo29CFU2s5cPgPpyb6c4nIISl1F2DC/v6mbZnh0hliXGBMakd cGF9s/F3uA/hvx7uT/T2EovScLg4HA7nqS7Ly3f9vroTDheDw+FSisubN/7UHWsvL89JwoW5 BqL4jh7iUzJ388fhcDhcXEIyvqqn733Ht1lZf2lZqIXcDWGNEIwfVWEt0D1ET+De0/M/7LnA KWTomFPROMxSZ+/9lhfpIH3vwNkTp/Viuof6KpwtFTnYf7h66r5zQd8obSyjYwNFGC1BaUUD hEMAo8ibO1pHRV5a1CF3cGwSAACGSZ1VdBFRcy0BvoeXRPVxOKqCbHpR/caf3331tYXpOByO qgksfO4+v4gOmnZldnV3xw7JK2Wkt7syLSkhDuehKs3Dd+OBhjN1UnC4pJyKCkbV3b7S0mgH RQFtm/BImmQsLjIsGCV1V9k2On4d7U8D0Fmfn5GOw/lam6je+knAIsR9vXVKUmp5y+QUGYBh Um1VtLW/6q3DAhYW/lkVzX21uZHuPF/dVAt2iK2p76itSvbWu3hXMwwTW9PTMQJ6a3NiEFx3 xQwcPZl0Aj2Q8ooKunpu6c3r9LM83d/UUEJJ2xkXRR0Dzt/bUU/mDseF7/54QQip619c2Lix BUGujYjQ52D7///4P3tOiDnmZreA3VtZYDhSeM89g2AG2d/o8BBHDR5RIz8Mk2tSSbS9mbyE oLZzRBRdwTE0PAStzv2UV8sPk91CGe7pKsEmujy781RRUS8gq6iRKorbW5dX4K2OVOA9Keke lljR3D86AcBoS3GBqywfl5Khmx/TIrPV1JRSlzWPyKGQ++qzsgLVJcRlfhG3T06raKFMVXiL KcuK/qIbmpJL7KNMJxnz66sr6obm5la1UjKsVcUV5AxtvOh5Rsgq8ly8cOb83lPS5mGZJb3D 25ZIeWeePERVpK7/dJOb84yUZ+loB/Np7LIgVX01eRnDjci2BgrPrl+4dGzvXm60VUQJdXdn hkIeqs/MSkvA4XC4UGcfY76DP/CpWXkG4nA4XEJSal5139TYFAAAUIa7uyrSEuLjcDgczg+J kOM7flrSAkNdwMnpeVXEkXVZxb7iyBArlUdy5hG0pYMLcA3Q5r198wjbj/e5lWzDGBp/uPXW 5RbgcTgfCx/VOz/yW1l7YnDJuXlVpBEwMwuGWkszsebiog8vs983xETGZNf2do0AAMYnxogl ifHJ7spiNzkvX5NEJCTkFhQkJ1upPuX+5ZqkYVxSDL66ZWBsAvQ2Z7hb3vzyz3/4nyv6NLhP zWSgHkJHTdWMnknq3eDibyB7S84HV9e1s1PQQ22kikh/d8Ubf7kivS6om5qCr2idmmbYnKEA QEyyEdZS1tWwooe0QalLPjp1+syhby6phnvjmYV8SUnhhlLiXGJSLrhoLA6Hw/mZaWgIPnoo buRdNdG1vja6+0gRljy3ZNRdbJhGY2OqJikmZmQc0zpBmemtzc33VDGS5z8r4xmRXNUyODYB yMNdDUVRXk5CBx4p2RoGlZQQWQh7v2O4VRURaC8VzgP81rbBOVVt/VWEQGe+766ph7vE1xK7 akqxbnpXH2pGRsbX9nWN9BLzQp1l+Z4o23gGhDN20VpdUFLdzDqGtrFQ52muIPMLl44Lo/Kn n7O/gSyHrG98PW1SyD2gxFiIU1RCzcqb0Z2riYW2Fj8CWz05NQ4AAL3EPB9nOU5ujSjac9Ev 2E9HjOPRle//cf6htJxbfn7TCJVB9xZgAixUGbVq/ZwtdAUuC948fEaJVpaHaiX+HtrKonKG aByDwGyIRwBK6cljWdvkhuqdLZ3BvvaKXOr3Pg5np/TLs8ccvxitTzcuo7S0ib7/VIczlVV6 xC3tgothyE6Qr4HYTUIr4McAACAASURBVFmHhIaaHR7cnxzq7ChPi4/D4dwURJ7JcktvLMrk vOoapkdPQ3mqnRHP02dG0X6h9FaROJyDkaSwvKEPQ37aC0ItkfLSz/RcsFh6L4ND/VEqjx9x 6wTHUiny5CBoDLRUElNQN0czTaGLk7miJLeCadpU+xAAAIz1tjXmricHZ6ek+uzxvkfGtDnK yClt6mZk0ACA0Q6Qoct3X+Tm6TNcYuJKsa1TWx5J7fEWFqoK0hpoJoFZPycfbakbv5gG1raT AABgeKA9PVDhpqKehx1DD61U+QSufn/q4vULct4xqdVtQ+PrOweUHkCylTqzj+1PXx24o6Ad 28qqouCOrD0vWEdHjPeBjOt6Jn1MzVUF7z6RkfGrI/aQwWBLaznGy1Xl5718ho6hyTWkznEw PTEyVJtO8FUSEpHllXVJzahqn5mdBAD05GUHIeUExJTtsEER9NFgcDiECh+fpmUcrhYAyhgg FWWlmSsKSQjxGXvjC2sGZ8nTYLClojzM1FXl/l4+O6ew/BrSwHavCH0s+4+B+yuv4YvO+uK8 HAKBgHX3MxHeu1cY6RuBJRAI2aXF9YMvaBTjzfPxseYCAoFACFB99lj48TNUAE0bLa+2s2tr yZX32+sZ2BtpKyCjbeHiRhdZc9LSlL175vTFE4cFDQlFFWNzz99s74nZBvvbvCWP7T3+nTg6 qrx7vKwZI8a+d993Z/Q8kptoZ6jXIBypirZDq6nIbQyCQCAQ4iJDLCQ5hM1ic4hkCCF8s7A2 WldWQBURDQp2V7n6P9dUPUOCCQQCgZBTWFY/RvvTdIHyvLuK5sbVSl3i/hEBQwKBqqZaUN3a sd3Zw022trY2N1BXX5pNwLr5IIT37RMx9Y/EEggEAiEzr6S488Xca5qc5+vp1Z5IGxWEpUsg o/CgD1rDyATtsFE1A1AGm6oIhHR8mgXvFTkthNlG66qWkennEL5ZeD5aiy+w5RWW0xa3Si5p GAQrywTds3LK2hqB1eUdgyvLdd68QsbmtoHVrR1TcG11pT5ES1tDQ8vSjzGNMf6OVpoy3GpR JSOzLyGEcGysM9aGi0fPJiKQOgZCYjrew1Ra9NHJfRc5ngg6FGXUj72kHUdfBn0zeBnOH/7x 18++vyLtgGnckp0Pt+muN1F8p59qaTPL/oY5GhgYm+szuX4x1V8QrsItoWnjGkRXwU0nEPwd 9JVkFMz0MY1ra6tzA3V1CeYGGvIcQg4ZmQ29LxcXIJynDHZnB6QaXP9ZwtI0oKChe3IewrWV 5ZF0aytNDVWEcyBTbPdAA6XbvPbxQ5R+ckdHrrenmeT3N4yDMAUtI9M9VdExere+F/UKSqrv Jr9oIoT5SHOIemUk1Y+Ta5ISHY14xQw8CYRkap79HCzl7z2+cYTtR25p0/CMtuEdvYrCaKPl EWHaZ48JCl8+yGPqU1jL7Gi0LjESxXdPwSscux45KsRS8+njByfZjt2TkXTMqOxcv2CR3NFB FRFNTyP4KQk+FOaWNKcNv6Cue4KqDLy2ujLXX1tbkk0gEAiJYSmuwpfOCCuhPMMJBAIhKyOz pIW8QBWCfUXp7QhXEVFBOfhErLvBpxEc1VWFrx47c+3EbW3vzNJ6WuMPt/nJ/q5KAiEthYDm EpDVlUKHE7LyM0u7yQtLb+Di7AipKtbDWeh7dg4lfYfQwpr2zilIhYP9xIqSaGd3LZ7vP+FQ 8gtPLCsrKYnxc1C6/gmHul94aF5dY8/kPHy1vNSepvrz9b1/PvSIAe5DOFqbFo2W5NP1io5L 3lgS+FSCg7qKjqNNQv3YO7vMypbmloerivOsFO9wC6wL6mYQCNWtozPMR+4nSfkebup8QsaE 6HhqyFCMv4H4jUdX9v/tsqChYQSzkO9zUjfeTvnyNVGrcO9YAoFASMD4u8pyPuaVRcfX1q9v Va1AWJvqrK4vr6fvyri+Q8P89CU5BZS8q2oH5uYn+rsyfZP0b54XtzEPKiL2Uubh8urybH9N Qbwpn6qC7DOn4qzG8fktarTvGO7McFVSnuUTPlk9Wbu0MuLwzOLLNLUj0iqGuiG1VV0Dr+cr 3H7hMbZyDKkldU29evOqLdVcTk0DiXKLYOxiiIu5vrKUsHP5GLXg92RZbYTuqUPilqHYDfHd tBSCg5qSjpNtIsOkDODCzNTu3tXyJhBS6C2xoUloWW71AGzdwDSEEC6+edWaYvZYU8fezHPd F4Fgb6ok9ejUTxfOnrltkpVYOzH58g2EcJHc2RamKqhs5kxT8k1LSbJX5VZ6fIZTnKEsD4Rw uKo5zITnvhwyCkeXtSXgUwh+CB0FNQP35NwdLp3lt8OthXn5BAKBQIjyttG98bc7GsFO1C+F 3JIcIl0ieKK3Mgxx+rC4VRiDNHEagWBvoqhjZp+8U+66tvJ2rq+6ujibEOXgjJQ6fBsRHpVA dZpVUF7W/fLVG3qtJPBqLstXgUdN28WO6Ys6xNtGV0NBTy9uYGp94xqQOzJDVPieaTp4heIY Oulrqy0vpWyNimledzlRkh1ooiqlou9NSGCYwuQElCqXgLFvBbUG0+rym4mWwnJqdiK9YnVu st/RRK5rsudm5RAHFpc2/+JpjwpEKp8/eV/49hFu3/KKoc07FqA1K8NZlU9Q3yE2YSORqckE exUFSWNUZFELhBCuQDhUEqhnqW9kuPHDiBDsZKrFffb68a8P8FpYhZY0909t/L6cSYtAPD7+ h7/8if0Ct3tF7Y4VuTd3c6w9MVDp6p1nts5+cQQCgRAfmuAkw/2QR9wqOZU4A1+/eDNUUZCL luGSkVdwiKlo7nkJ367ChbG2tkxXR4T0MU7TyJiSdjJ4CSFcHJtvDkZKimiYentsrFoCgeDp ZKKsIod2q4AvXkM409vTEOHpqHH7uLRdZHpJ39TUa/j6BWWoPC4X/ZBLxkDRMb2ieeQlhKvb dv8/3P7VcL8rM8td+iIb27db9c5OS2t6ZzbTGjZjtDQfH93a6tsfjl00IGQ37PzccEdJh7fA iUP71h39cPmnJ1aEPoyJyO0rbEcvP9V2qgGjWw/Qb2NNGV4a0px3TqsndA+RAciOspR4cJKT 9k8my7YVkrjCNJajT7R1I5o3WlRHJRg/eIcaHNtVKZuNIr/ZtmixK+9q+dAkNXaH9RSG6jJS 9S4eOcBiWo491WHqJACgo7jdS+D4wX30Nt8dPHHJMCOPSIe94wDE2QhwsOriqaNnNfz7R7oA qIpEG92nz76sjl92TlGclwDbj3vZ2H4xtYsl1BFc9C6yff8N2y+meFwtAABQhrqq7B88vHiA yeUvpg64TQOuKooz4mdj20uPek9CIbAtVOYYx09sbNdkJDaO+4G2RGuLJ9/8z9+++1TQL23z oeIdWlUEzvDe5hF/f4xNyJ/AyjOpEOfJz/bDXsa254UDB6hth2rxyboXDu7/ho2NjVEUN8ua /9nP1LwfYrtk7JvftH6ecawX4BT5bx5nin5GTj8wtwWAyUFSld29BxeoqTt1/IJW4MBoXoiK ysMjbD9ePc3rmj1MTrDiffYz249XeXlda4fJ00Tqp3R7ZObo7Z7mJH6B7cA3bMJmGVV1W4f0 gUYMcVV5ePL0gwtaiUNjWzfqiHgXZXEGEdHrcs7mfmlJOhd+3PcN2yMz5/g6QB2R7d37579n scrYfjx8hg+RM9I8AgAAgzVpidRrWdixa3yGbrWAVk97S+Mfr515Yp6TZy5x99wRtmPX+I0Y G3+gZVpyi1zeFJaH3yimFkxOg8pg5bsPGNNsnpVYDwBo625ylz+4/xjt/w8cOCAiInLsGO0/ vjvMdhnhX9TSAwBoy2904zu4/zvatRtWEYbUu7spN9fOCbhvfUVge6sIi9Ld5OvMyZ91g0fG t7zukhGGFGZoeobHMMQZE+XGx7bv283quwAAUB7K5Pk4ryACW7u5UscEAJVBipz3DzN1gNc4 FEsTJMiw4BK6xMbGxsa29yjbZWRgSUsv6KhKttc6z7aXKs56U0HefXPFrndZeaixDictzllF 49D87JwIV162fd+ysT22dEvKoIri7mVne2yZm9QAAAAjHQ0xst9fZf7iOqsYFJrP8LpBY6Cj wv2TbMx28MZ5QY8CWhl9AACY6AOV1gp3zh7e1PI4nxAyto4pOa2kOmfZ7/fSwh48dkHIpIAc ZPBE8BLbwRtCQp51ZNrrQQOVSTjN8/tpSr4Hbwhxo+Jz9U9s1NynW0dKgs2z82xs7Buxz56+ ph86PrlVBXbbXGZjtHnZ2FjegWwcSkqedLXhxmQ72WcnNmfn+CUR08LJXZyoHqhIwGowaPMy JpLfxDR2U9GqgR4i1urm3tP7mVo+sS5MadzsuSUrzImHjdHxOzRyCUH6AneY/P3E8QzlWbex R7jVFWN2nqh4pW6+F8gAVATIcnAeZvkpzUoDw7SYIx/kuPzMq5gyPcbsyl/6JifDOjurEuZo rm8lcoJt33G2n1FhlSTqmGYHmikBjy/+8OWf9j/hN42r37TlsEsrzQzR5NlYZj9xiJp719Pe 2ygNCNGkD+GsACoqrg2Qu+orLK7dPEWdpHPnbhmFT03TtuyaWysdJL/9hmE0+9jYflbBVBdT xzDYCqIl712kfn7op5/FzEqmO8ZBaYCOxm3aFedUUFHF7e/o7se2/xi4/2oCttgrcJw5ulXv 7Mi9m3KYFgipx5hniPhk3UssxeBOizs4ZW1bepmVFVoYCDL4vKTrgA+LidLjZz/Azn5DN7lr 56cRZ8idifY32E+LeUYVD0DYP9DsIfPNt0cFqP9ksv6iSA9+poEcOMNx06F1Y6MCDKwmyTy4 zCI37OzsR39+KJcCh56v+yK68bNsxs7OflnIyKpoZ8NYW1vtCZORvXdkq7cDZ2/fdGjtmWRg C2ursACtL8A0O6clnFxzGHlPY2G4DqsufsvOLmAYW9YE4Ww/MVGG/SI15tEHtxXDW1aWM9D3 +C+ys18WfmSVubpMDJO5fvcI+2VhhE3xut/RDHtb0VPMAxZ+Qv943WZXlhPNOC9cpEf9bq+g N8nDXFfnLjv7sat75VPoddXnh4lVhgcPf/33v9zQMtxae3hHNtv3Jl6a88Jh9k1239CElefV 5TcFZpy8F5naPjCKo7ZdXXnbHSotxUlN0PG9+xW9SSNDEPYVhLnw0vMupcx4nrEhJEybk8nd 0YecKpGtEL6GcIRga/PsFG0WBI3iygsaknBaF9m/+Y79soFrZktZXogLL/s33+27bIDPbAHT 9Qk4LYbOXRHlMo1ZqreRvHLiCPsDUVRM8dYhfaBN17fitK5/t2+/oE9CxdYDqtMjLbE219lP 0EREj1/nUUhaKnKTlLxzmP2KKI9dCbXdSLqNlQjzYthYZpel3LKpKHB1eak7WELyzpZ5YWdn Z/9h735OQ8JAK/2k/qbG3+5lv2zoFmzvYSlygf2HfQfuMjb+QOvNDXLm3RT2/IG7LoSBaQCH 6+ItNS8wpFnM3L4UQrgMYV6QOvf/Y++945rO8v3/3+Puvd97d3b37uzs7uCM03YcdayjY69Y oxKqoFIUUSygAgqCQaSE3hWQIk16R6RIkd6r9DQSIAnp5dA7yef3RwpJwFF01nY/z//M5+S8 3+d9zvlgXp/zeb8PyHwJgUAcOCDzwUZD0wfFJAiCZqeg57bX1DZLvisTSnx98jmlX1bI9PLV N0rbrP0Lu5Z8PJWLH0s6t1eur+VKSqfupNd1KDbtwdd7nVNSkjRd/euRa54tY8mWe1U3K1bf hSAI4uDkev5hyw9HfPPIvEHFbimNyQ7XZGKlpLR6C+KGbxfEn4IgCOopDPNUlwbn/LXAkl5o dHq8IUx3y37RfK7d9+NV2cK2vwUHV5t4VmnjjyI7KogbCW0TIzl3dqtuVlLaaaDlmS8qirv/ J6WdBk6ekrA3hlw1VZab6tUqN24kyLxuwGlojb+2S0npW9lGX32rtN0moFicRl8y3Kwkex25 4SopKf1r649H/QoGgExwZiCoMOQqUmL2KyWl7UYBxWHRIe5qSl99++N2m4JijOSo/tQYPvT0 GUklX9HVcIcLcjn3RYz2j9Q5nv51tcy2+UZJ6fTdrIaFVWBfBXt8KMFm5/pNSouxTnnVtZw+ cUohTl9zjOMupdXfyLb4Wklp+4Wg0jLGK8wsZG5yBBdySqY2r0wgt504JqmRK2EWgnBP7E+f XCvXctc5V+9qxZ6nR0Gh9fbjv8i1XKxGLr670s1ASelfMpa//+nEnSI6bui3upJG58efr4dT uQseppDr4u+abH7ZVQiCIIjVBeIMtq79QSaQ3yttRz0sw8m/MECujbU12Tzf6mfVm5fcU6rt d/6y8hulXy7eDJv/38xsuZuLzpo//O/qrxH3C+mDL0uktRRYI7zY21vXSkb/rx9WqdgWs/Ci rlmdvFj9X9eIhvDzDlXL+xhoaBoiZ9raaokm6VslpTP2eS3d4t6mICg/6MKxfXIx/EXtVniK dAz1Qfcv75Osqx3GIRUVTIjVWRajryS2s0ZN1TIFA0FLPuzxsfG+xX0ukznQS8DMFxKcB9/b L5OehkPv7yfiFrbC4nAEMvNN8hpzWdwBEh4nsYwl4IgUJo9O7u0hYHAEYj+V/TqpWhXgMAf6 e3ukRXGZdEov8SU1cplUUi9BvrAdsV+cVkUEm84gE19SDQ5D6KVSWfN9URT6koFIZtKX+GID j8NkkAk47CLTouikJJI43HxjLA5PIDNl0gjwAWBQST2LuYjH4ftpPB4XADadMj9cfF8/jcli MQZIGBwWgyFSqHQmmzlAJmCwWAyRwmSwAQCAz+OyqUQiQd5PIoXKUBgwm8Ugk2SWGb6nt4/G ofXhenAYDKGvdz6UoDrc6vq2ZX9bfsaxBd/JfosykUA0gz2KI8biMCQac7GeuSzGAAkjG3Us Dk+i8URteWwmo186KfNFcZkUyULC4jAE8gCLI+6axwWMPlKP/K7B95FpLI44dD1EPFY8C4R+ Go/HovX1EXEYHAFPGmDy+AwKqZeAwRFIpAE2j8/niK7KxnlggEntxWOwWAyJwmQv+VmYFA5t oI+IxxMJ/QzeIruOw5QvIkroo1JoTEY/HofFYogUKoMDJCPqwS+yaDEYHA5PIrN4oiXJY0u+ u1hLAok8wAbS9BKKjXEEPJHCYlF6e/C4BY1fk/kpmzdLIpHpbMDnAzatr0c+zEwGB0gqM2Ol V7BYbG9v73ypZiwOQyDTRLPPZXEGSDgsVvLdedg0suKSxBHwpAEWj7/keyibRu9X6AuPJ/TT ePwFi5tJI5NkmuJJZBqVThetdoXqu4v0LA6OgnTIB4BN6+uRX+B4EpkmvT8xKUSSzNagsThc hdK1ioVtf3u45Hmn8H1kGovJEg8BQ6QMMJjSnokUlijsPC6H3oclKG5B+fFyaNS+HjxGHtGk 8GUmhc8DbIq4BvKClcORCw6Hy6H2YaVLBYcjkMgsPo1MJIm3M4cvWbIKtWpxBBKmrUGuoK4U LoNB7ZX3E48nkGn8pa8cwGbS+0mL/t1XnBTFAsKSEfVSWPw3SP/OYzPosrV55QJJpijsFsDj cuiUHixe8S8MS7EhABwmjSp/935JjVyFvYDBYHA9vZQBzvxtZGFXstEh9g0wX7oXFr0qjTqN 1q9omdArv8xEXfXKbSt8H41KIVNIeAwWhyFQaGyuaPky8E01d9at/erHPZfvh9UzOL+PuM9m 0vpJLwuO3BDwJAqdwQV8LodNIUju/Hh8D5k+PyIOh03tnd8LGHEJaDqbJWrB4wB6b494i86v KzatX3azU+hvUzH6rfhoxH3hHDQ9zGczGQvrnTE4bP7YtOS01Nz0xPgga/Fyfrzh4Yk3Kuc3 OTTIlemTNTg8MTY2Nsil0+l09uD4zPTcq/uQZ25uZnyYTWfyRsYmZyFodnZ6hE+nM7gjYwsO h85Ojo1wFUu8sYenZ+aE4haCWeE4n8NaJDZ0Op3B4vDHoVmBuK9pxb5khsUdHFriu/JCoXBm jM9nL2ZawUkIgoRCxUjS6Uze8PzpfgiCoOnJMfASF7mD41PTECSYnR7n08XDFc2+UDgxxOay 6HQWjzM0IRROj/HZbAadxRscloxodmJ4mMeUHzCPM6wwYIFQOD7EZsm6yB2ZGRkaBGw6ncGi 8ydmxKGEeISGpJP/9d1f9xgE5laOvd3PecGscJzPXjiDnMGhxXoWCoWTovHKtR0XtRUKhTOj fElVyfmiuHILicnjj8gstenRMcCW647BYYOxGQgSKoaOOzg+NTk9Pg5YdDqdzhocmZiemhwV 9cwanJiYFsxJr0rjPDQmnB7msZgMOoc3NPbmGRnmpmdEXXNHxhepJj03Oz0+zKJLfWWyufxx 4eQIj8dm0Fk87rBYj5udGB5SWAyy7o5MiJakUCiUq88pHyA6nT04MTsjOaW5SGPW4Mjo8MgQ j7Wg8WsyOzk6rLAZGCw6e2Ridk4AzU6PD8mHeWh4ChJVZh4FcpWZORwOmy3zAZMPRLMvFEKT Q4DLknxXJpQzU+M8uuINlzU4Mjmz9LvdjGCct+DmLd7O8szMTA3z6NIysAwWBwxPC8YH2Rym YvXdRXpmsBicEdn6s9JATsnHStTzyAwkuj/NyMZZHBz50rWKhW1/e7hTY9LQMTgcMDYtFEwM sjhMOp3F4w5PSHuWDfv0KFiwBYFCWqTpMbDI37aFkzI7MT7EVWwpDo5AZgyipcKRMcvij0yO jomiwWANTkxKlqxirVo6gzU4gY23WETcF8wKpoZ4LIb8fPOGJqZ+I437y2IpEIwNspiL71W5 SVEsICw7osklL1nReLmL7n3ZGrkykZyZGOJxFf/CDCtsKwiChALBpGgxyLBYjVyFvUCn0xl0 Bmdwcm7+nrNYV9LoMBhgdHZuwdBnp8aGAPNlV0WxnBGM8VgKG5Y1OKq492enxgaBjHUGd5A/ PD41xGIy6HQmf1DmVRdysoXZodXfbjFAVY6wJgS/x9n2OcGc7NpgMBicIWlw5mbm5ofAYHEG R2YggRCaHR8anJ8k3tDEtCTqQgiaGOFz5Lcgkzs4Oi4dw9TICF96ncUfnZyag+ZmJuc3O5PL GRwX/dH8tHnf4j4MzIdFTaL9KeTPmzcZJ9ZSmMxXt4eBgYH5ZCAQWiKt1q4x9MzNbIPvfzC/ AYX4Is1n//9+t83QKrQY+77S1nzqfDTiPgzMhwW9ryXE5Kv/WHPCM6S0d8FJYRgYGJhPmFkI aky8aXDjiotX/VumWIH5tJmDIPIze3W1vYd2m8YShqDpTz5tzacOLO7DwMjQHux2TmXnznM3 8wlU9tLPhcLAwMB8RPR39BSG2tvdRYmxuH37yvnzbpFFmM63qJEL8+lDf9Ge66T+z7/vvR4Z W7n0zEwwrwcs7sPAvAm8hvYEkzX/sVb/UXUNffzV7WFgYGA+XuZmIHxeRtR9tBgnNPqaubmz b0x1y1vUyIX59BFMQuwszzMHj6mZ3crofXV7mA8eWNyHgZGhOiLkrp3pvZjnACwxlREMDAzM xwa+pjPWUk3lOEKMhvbZO0H1LIJijRgYGHkoLd15vhePG3lntTaS37czny6wuA8D8ybQWnBJ Lmrqbml9rKXnc4aBgYH5qJidghqCvazOI8WoIZHGLmlNsLIP8wrmJiFyZqitrfODrOIl1+uA +RCBxX0YGBgYGBgYGBiYDwtY3IeBgYGBgYGBgYGBeSWwuA8DAwMDAwMDAwPzYQGL+zAwMDAw MDAwMDAwrwQW92FgYGBgYGBgYGA+LGBxHwYGBgYGBgYGBgbmlcDiPgwMDAwMDAwMDMyHBSzu w8DAwMDAwMDAwMC8Eljch4GBgYGBgYGBgfmwgMV9GBgYGBgYGBgYGJhXAov7MDAwMDAwMDAw MB8WsLgPAwMDAwMDAwMDA/NKYHEfBgYGBgYGBgYG5sMCFvdhYGBgYGBgYGBgYF4JLO7DwMDA wMDAwMDAfFjA4j4MDAwMDAwMDAwMzCuBxX2YdwyDQW3OD3IKTiopbae+b2dgYD4VOHSAz0sI ePg4o6K273078w7BVWamRQX5pDWzOLz37ctLIJXnx0WEhT953gO4/PftzCcPHUeqS/Oz80mu wHbR3rczMDBvByzuw3yoCCGIiytLyUhMT2/mvm9nYGA+IQYx7c/Tox89qWBCY7Pv25l3xSi7 vzXFzS+lrpM8+L59eQmjFNqL3BCP8ALcIGvifTvzySOYgdh1hfFxyU9rW3nv2xkYmI+Hj0Dc 53GYlJaCwuy05JyykhbS+3YH5i3p68em3Nv2+a6zXr7ZuEWu89iA0lJV8DQjOTk5OTk1I6u4 g0VmLNYTm8og1Oanp6YlJycnJz95VlqNAx+svgcjD7G7oSQ/OS39SVE9iUPjvG93PkDYFDq+ 5lmaZHkXlNfgAfc3ljeTBCpRupt3qpsERrb9vq5wAMA2FuVkJ2fmFte3Ut+tQk1srCvOTk7P zXre2svlLVwp5UGmxsjtKy8lUxkf6jJqemB/CnHgyA23OsCGb1BvDY3U/aIoOSUlOauys7uP pXiZVNEcfWntf606H1hWSHgf/r1XWGQcpvppSkpycmFTO2Hgfbvz/uipr3n+NDk9L7u0vZ/P 575vd96YT0zcn2DicY3PcwtKcptpg2PT79sdmLdBCEHYTDvNMyd0dEJwizcZZ9CwDSW5Yio7 qIurdkIhNNKHa6p8LmqXl1dHHOJ+Ugv/E2Z0lE9oys0tyC1pIjBhxXMRhAJopBfTWFEkWt3P 8utJI7zx3/xKX2qM1ak9mw0cWyHO5O/rDZ/Z21qbm5+XX9nBGBt6l/fgUSYPX5ubm5db2tHD Gl64Ulhd5VGa/71M0zexsv8durUUWFWNjy6v+9OvZk/6Ovjv25mPH8HsDLOjtLo4t7C6rY26 4I4/OwF1+VgcOaRm6B3V8z78e68I5mZGSHX15QW5ZU31hP/Dj89H6GxsTW5efm5pF4kz8jvf Dj9RPgRxn8vjPUGauwAAIABJREFU0ckkKoPFWfQHGJtKrPc8fmKz0p83nlS5l/uuvYP5nSGT 8VkeiJUqpoHBBYtJL2wyqHO/htiy6ssv//63v/5z2XKEP7ECu2hPTfisW0dXfPf9l19+8b+f /Wu7qmE8oDD/ze7DvB4sKplGozNeqqnkP7Y7c+BvXy//fv/1XMoLyrt07SOhv7473eLA98u/ +/LLL/7y2YpdWhcSAZ398vasPlDrcuXQiXO3IxI6f19XqAAkOapu2/in5b8cve5aC5jvUirL c7Q5ufGvy375/qBrPo218GWf6kibm/rHdt7KHGC+RNznsrh0MpHKZv/Ws5F/Jy/CPI1Pa+qg 7jfB4v7vQGdBtJfq37/8yx++1wsKXajf99W0Jt7au3yXWXh1KfF9+Pde6atOTTDd+PXf/ue/ 9qG8Upvetzu/O2wWndyLeyk9vWQKE/D5AGTbWmhu+Hz51jUnvEo4vI/3FY6PTdyfGh8ZGx2Z fNlh04F8Lw/dn//+/Zo/aCY2E+HDeB81QgjqeeZhdFX/0qXHxMWbDORluupuUVJSUlL622f/ ucMkKqxp0Z4EUE+U+/lD65WUvvzHF5//8Q+HPdpKSP9O32Fem9nJifHhwZEZaE646HUiscnn nNKybz/76aRrVi71HXv3MSCYgQjhaH3ldUpK//z7F3/7yx+P+mAq+n7zK5TsVKfLakeu+XRB vN9ZzWoqDDNB/n3Z53/ZbJLZ2/YuFeqewlp35Jf/+Pz/rTBxz20fWHCdg6tNMvpuo1FoZv1L lpFQCE0OD49OjE7N/Zt9fQmchtZ4K+Ufj9rlUzAf6tsFHxHT40OF1tuPrf7sm/1GRgv1+7lJ CBdif1rnnFlwUu/78O+9MjsxjAvW1tm+7M8btI46lr5vd3535gSC8SE2i818CSwWf2xueg6C cDllLie+/ErpjyvN/Iq66e/b74+CD0Hcx/UTo6+pOCcUtuAXu8zncdlUIrHY087O6Tws7n/0 8HhcBpWII/YP0BbVCPk8wKb2Ewk4DKY0KcBZbblG0EvEfR6byyATcVgsBvPE67LNeVjc/4DI dza5HxiW0PGy60w6pbcyIdxDe79VASzuLwaPzWX092CxWAwmw83o9oVXift8HmBT+3qIvWQa /Xc+ws4DgE4hPo+0vHBN952L+0wKuTYixO7ajoOuBYuJ+2waub+XSCAzePyXvFDQ9bwj8vpB p7KKzvd0kJlDo/b1kkjkATZ4mY8wrw+HSSc25GdeW3XY4tEi4j6PzaGTe7CEfhqb9fEe2H5T eGwGvaMM64vYpOf+KYr7lc8izdSXLftq2eJsVrt25yng8gBgkvtJGVEBaP0TXqWwuP/uKIv1 CfX3LnjZMbvZieHhnoLyeNQKzcROWNz/uBFC0MzEMB/w+PyxmcWbzE6MD/NYdPoAlRJ/ee01 9MvEfSE0MzbMZzPp9K6qnKATfzgbBIv7Hwqk4vREOxOfrpcdIZ+dmR7hkPvjLx5ziYTF/cUQ CqGZ0SEem0mnd5RnBiD/aBD8KnF/dmJ8iM/lgJc/U3ljpidHe1rzg83XbUblvFtxf2ZyivGC lG1+cB8qYDFxf25mapxPZ/JHx6de8nR4dhJ6bosOTgsqYfybfX0Jc1PTY4NsBmdoYnZG8H5c +JQQCgSTg6yWsEvWVrcWEffFG4fLA6Pj/2eSU0kRCgUzo1xuzj3b21aforjPGuHH3d66btNX i/P9ynV6kbQWOgTNTEwOd+Oxgfr77ONgcf/1+BDE/e5eQrDBTpvInMZFJVwxLSFebu4XYHH/ /xJdRbEPdJZrvUzcl6Eq7JbTJVjc/4B4aqPn6nk/ovW32nQUpD3U338bFvdfRcXD6w5XXiXu /9tpSnO8Zqn/zsV9AEBXapKn5Z6XiPuvpj2vNejcBqui4ja4yMcnAh3fXGG99rhl+CLiPkxf O4hQ33bW81MU90uyIu1PbTnvEp8QnZiY6GJ85fSJ70/YxMUnJCYmBlpqm1+/ZpoqTV9WkhXj bQSL+++UglAHH7T9E+xvNOE2dec5r9ZM7ILF/f8zCOZmn9385abrS8R9Gbj4+nitP5wPhsX9 DwV8blzEjTMOrdBvpNyZm57KM1f1egyL+6+A3V0Zq/3Hc6GvEvf/vbD6mhLubtx8N/fdivsQ BI30jtXePX7gbuBi4v6rmZmAckwtvWI9nr3Jt2E+THqTLJzuWi0i7sNAEFTl5WF/51MU9+nD /OhL2wzvooMeZ2dnP74fb773H/uvo7yjsrOzk0M9vAzWn4mg1VEljUHspQOOCbC4/3q8X3G/ vTY3OhB1/aa56sZv9mjoX7mBmifwSXOt7M92kbh/M4JaEu7ieA+FQqFQaK/glAICWHg6r/1Z RLSPTF8ot+CU0uret/CUgqGUPJLYRaFc76OjSkqjHFOLWurktIX22pzoQFnL6OCQ1BoCADI+ MpgDLflBaC97yVU2nduQGO7vgkKhHLxDggsIdBYPtOflyI7BLSaltK2ju7HkEUrqxXxjAAC+ pjFDzrLcVRFcJsDnJz/0QqNQDt4hIYUEOovXnhce5Y1CoRwcXUIyWumk1xXH2QA05D3y90Yt /K64ZK6nPQqFQrkGRCc3AiYHANBekx0VIB1Q7KsL6r4zcZ/R09qc6ulkfxcVlJVf/Ly1MNoT hborctQ5JCSthgCATBzJA/3FCc4OzigUyjcmuqCDy6DgnwUGetqjUCjXgMeS8UqiQWl+FiiO BgqFsnN09cpo6+xdxFEG4UVzqqfjvbuSZRbgGlPanuWfWd5Z3zPfrC03LNJbbnmHpJXXLKyh ymUA/LPEQE+02LATyiszKyk48WluukJrBoHclBrgeE/so4OP8/308id+4U+ryjuWdtiZ3FX3 PAzlYIfS27vh8NHjGqYybvrGxhTK5YvpKEh7qL/ndkFzTFhAkMhLe2dURHkrfoFRXFVdeoDs mB18wkKLCMw3r7HAAQBfmRAQKIkOCuUVl50cmfg0Ib22BwAeAKSKhIRANMot0Cu1iSG6y8i4 4R5XVtExAEA/tbcozsneGeUeml5RUF1bFIayt5NMTGBsapP0BoXrrE0LQ9ndRXnFlXUXFz5J kxmQb2xh0ctz6bxC3MdV1c735R76GwV1SRUF8YGusnH0i4tdxDATgLrsEB8vSbBRqIjs9vzQ txD3KS0Fz6LkLLsFxaU2LVYkozU7M9xrvt3D7KKnIQvEfTqtvyH3vr27vbivxQvqiroyNTBB /qK02/C8qSVqfkSROR09illbcJU1aQ9kgxMUlVYW7/O4itXzBof++zuIhWH2dqLt7Oy3SEFd JgB12cE+Xihnv/AneS+I1TH2PqIF6ejnEf68i8NdkFH+daAP9Nbn+t9zt0e9YrwAANBP7imM sbdDS9aPm1tUZWWUd1Lx8ybF5n3tVYWhKDvJ/cnRL+JhZlNVtN+zRmyXOD4cAHDlsf4BTrJT HRz/vKlLph9sRUbKA5Sds6d3Vhe2Ij39kadkD3rHL1YFV8Gu+8P4+Pzm0tsLxP3Wp6/qCtte lRKKsruL8k6oxJXkp6dIZ9s94Ul1V/8Cy2RCQcw9SXDcg32TKzmY7Fh/NyeUs19kVnEP4C35 VQxS87PYCJf56Lg8ysqql7fc10YoCLW7a4tCofwTSoq76QOkuhxfO7d7KBTKPzihuAUAqVk6 rqE2yUPUGIVCOfpFRmaUcsMXivvEprwYWbsLuwIAMPrxtY/tvJxQKJR/cGJJC3uAj8uJ8XNz QqFQ7sF+GS3cpQ/4d2Verx8AAJT4B9qZrjdN5XB5AIDOxDuB6FuK4v5R+9LurGBfV9GSdPTw j6rm9dIV+8WUpSbflw2Oi39Udgnx/b9q85GI+3zAqEpBo73Q51QPIA4q65qh5wmIzS2Szdoi FfcLU3JjA9BoNBrthkY/zO5g0xbkoeaTWqpiZPpCe/kFp5UyoOGXnBR/LYhFErtoNBqNjq3K SYmtLMp7Lpdahs+ni0Ykwc3PObiskzMi46MQgri48tREX5mrtOaW7DA0Go1GOz/I7sTQxyE+ iS47Bq9HwWlNDKEQWxQe+0D6qaQxBEHjPGFnSnjAvGW5q1KGcF2liQ/QaDTaOSCnC0Mf55Na KsV2ApLKMPih148IjdicLXFR9rvikrkJvmg0Gu3s7BJbzezlQxDE49EqU9BoT9GAwl9dUPed iftCgYDTmJwS5okOiI/MbxXQSpKDfD3FM+jvElLWzR2Vn8GexuyYMDQa7R3kktbFGpwcxJYW J/ii0WhnF9fYGlYfkG3MwZaKoyHCL6m8krBIoIWCOU5jcnKYp2QCXdCxNRXP0lvqKotlxsXr aap4LLe874dllDOg0YXLexDbWZwwv178kuMTM2pKk0PLGTzZ1kIBxGkoSQ6T+OiMDsjNe5JQ WFqQ0bK0rM2CudmegtDHD9BmBifVd6w/YIK2tpdY9w5yS+9mD82f5JeI+zGhecVZUi/D8wpe LJBixjiz7cmh9z2lQ3F2cQ3IxeAYv52E/rcZpHbI2EX7RSQm5daUhoaV4/lj4xA0Rm1vzXqA dnZFx9W29wOpGyH+Hmg02isiM7OFB0ECCCI0ZD0ORXvdf5RZNjDTlhPy+L64RxdX97haTr94 MYzNzrTlh/jfR/tFZFZX4ShtyWh/D0lsHkZndENDL8ml8wpxf4wz0yb2Co32evAbBXXHqPQX T4LQaFfpoH2C3TO6ucNTC5pS8fVPZFZZeGJRYelbiPvTg3TK86AA73nLLm4ecXXcRcppcPH9 ZTKWgxJjsksWiPsCCOJ0P0+I8xX3hY5frKCuqCtHe7T+tt1HtY6ctZLZNRFJz9sUs7aMsqdb kx/6SWbFJ9gtpbUuxa+gurPtDQ79z81AhGcZUaLV4O7qEZ63SEFdCq4u87HkanNZRmaoaH27 ogPyqntYw0s3C0ECCGJ3FyXE+aAVxrvY8pmDIHxdRlSIZFrQ6Pj8/JTM8pLYcsXmc9OT+Lyg KMnydnbzCHiGL8162lArW7oWkF8UPLkvazooJLYcA0HSRTbK6nuRhPb1QPun1tTWN/WWRkta +kctVgVXZDfSX+Kiu1d8PagIXSDuc3Cv6mp0evJFXqCvP9o/6mldNbb3RRLa1120A6Min7Yy IUh+38xCEL42PVIcHFcPdHx9d0fNi4LY+2h3N8/IZ/gh9pLrhYzyqc1FQWgvyVZwD4iKrGIN TchYnp2C8Hlpkf5oNNo3NP4JRjA6ze4qiIv1QaPRvh7eTxoGx6R/PwQzk+za2LhgD8mkeAbm E0iZ6AXi/iif0lQUhPZ0kc6LYlciKLVpGSFoNNrXwyerYXBsCHS15MfcFw+/AUNdwn8R/g3M 6/U0CILoL7jRp7/Vi8iso0IQNESoqrbfYfiYrijupyZnP4uRLsnIQmwnS7HfEQaxORHt4y4N jru7d1R+z8jvXbzkg+b9ivs1eeH3riOUDx5Yv/zzFRu37lFGzHM9sCSvXaZtS4iXrYXq8cuR ljqHkccPIRAIBEJT/+rN+4XlONaARPMSVd8NQZ01VJftDHH6yh2n6JIqHGC/wZlTCgZfGB1x a97uIeSp/SdNr+74k8691KgasWUAKF3Vwf63DbX2ylnWv4z2z6p6wWRLisIO0PrKos20z6lt 3bhN87COc8qz6GR7Q10dpDJC+bDqGeS1xHoKk1ET+chOb8+WVT/8738rrT2wU8vRO6W6pqko +fYhjf0rv/n8q29WbNx3/qZFTDuFwQW0rrZUf9+rWrsRiKNSy5r6Whb+j/NbCdJytBwaaIv2 Mjt3cteGPYcPb0elPI1L9jHTNVRXRhw6fOKIml5QfTV20dq1C2ECUBhhrX1s9ep/fbvt8Omb /pUUjFhJGRjoLY2+cVJ7y/JVq9ds173nWQRoLABAdU6o3TUE4ugh5V0r/7rGwHfxgroyvDNx f6CzosRHV+vAquVHr5pcswq9dVZmBs8YXHbwf1JUTWQPiCV7Yj8h0VVb49TedasP6R+7EVKR EuFzQ11XA4FA7Dp+2uic24tuGpcDAADkPmxxToSDmTpSQ9qfivoxY7RfYnkLVvbZxkBPa1Xu Iw+HiwjkcXHDQ8jTh05dd9L83sAtN6YWAAB4bAalOT/IWu+c+gHZRXbG5K5LTFk1XkYqZVMY 3SX5vmaXdKWWVRDHLl1Q23j04q0r4a3zlhk9PVUp8fYX1aWGEVrI42dNNb7bYRp4P/cVc6RA T/2zhNsIdRXE1hVfr/557cZ9Ml5edHKIrZNt3FGQ9ODkah1nR6MzZ04hEAgE4shxtV2nrLzi SlpwMsEZ6HyR7ON1RX55a53VtnwQW9hOfJMpZ7PoXc3PfJyMxXYRCAQCcczwotreoxc1r0bU AsAFAJPp6npp/6/7VdZeSOwfYAEAQOvTZ/6miMPKiF++Wm8U9CAPDwChFxvvrKV28Mf1qoY3 b7h63tTZfeKYyE1l1TOGF5wy44o6iRQmAK11eX43lQ9uXrbyjK2fhc3NK1rS6OzVMLpteb8g uwbPWSwv/CvE/RdZeX6mCMQRBGLXuq/XqJktWlCXAwC2Kdb5nrHMiBEIZY0LhjZBWc9bSRyu eHWzKXRcybM0OzOdk2qiVXbkBGLXqWs+dy/oaZ7VfiNxn9j4LOyehYGcZdUz5y+5ZGXW9vZL 6ilzWXRyU94zHzPTs2rzoTl5zebWBWvjs5vlxH0qBV8UfkVVXxWB2Lluw84jixfUrQwLsDFE 7Nu2b93yv/y4Y8e+w5Je1REIVFhtp6ziDIiNdTGuTpc1d0sa7de4oKKidvXIStVgat0bHBDH 13TFWampHEcg9v66csN+5MKCujQAnoVaGGmu27LvkPZ5jxBr3X0nVQ4jEIh9+1X2HL3kXNjW TX2D5U3tx+aHX0bqq0pGcuQEYtep674RifVdWDlZs5/UnZsRbKG/77iKKDYHVdUPallf2778 pLNbUqNMy57OuuJ4LwcL7d3Hj0m6PWmoZmhzbfvqm9FlovopbAYJU+7ldPGUjuxU7zl5wcY7 uKShjSqWwlsy7/sYbj2wbe1KPT/Pm5dMDNT2IRCIQ4cQGzep3YqMqCTIPJwaIDSXpz2Qtbtf VfeC4U1/V61v91wLkxP3K0L8rc8hEAcP7N32459/Ov9wYUHdluqnPub7D2xSWqlp7XXNwuSy pnihbdmqbuQUkdEmY5lBwDWlxT0019srDs5BVV2kkWX8fYODazb+sv6ogW1wYudv1rhWhA0A pqEgzOfmRX3Z+Ohdv+4Rn1tL4El1c1x1R4ylyolje9YuO2yEuhX6NDHEzuTEcTUEArHzhK6J s28blcvnAwD6O2sLIl3uGiFkJ0X36p3EG9tXnnSRFfd7GiKDbS/I2d2voXsR5ZZdUt/Hkyby GiC05TmoGJ7cs3nFYaS2ZWBpQpKHyVkdNQQCse+43onLvrUk7u+d9WtJLFHcj7Q/vUHHzfWK jo6aaH2f0FA7bZOYXNkvW2yY2l4W537tkuZ+2fBon79hE5xX0sUbeKMnbL8XH4m4T2cQU12Q yDPI7etXrlm1cosycp6LtkERLTJtuU3dWajVO2+H3Lpww+jkIXEr1SvOyZmNdKbMD+wJJr46 ycdaT7Yz5Em9C2YPcgu7BjlvEJjpMYjWXBVkKWMXqaxnbYj49fKlq1YF85YBraoswfrsXqT6 8XnLqmrmzo8Lq8gcifIkhCBqXbybg8GBg0eUl/18Nzg9JTfK0eXaKWXkcSRy38FzgfGVpEH6 i54UayRy77plf/rmx43rEeYmbnlEoaA2wtxWd8vmn77/+19/3KyqevZBeXXPMDQFhvGlpY5n T59SPzo/aFXVK84+SdVymhe7rjLW4QLiAHLzsg03QrwjczMeuNzWVUYikUjlg7oO8bHNr58T Gt+S52q2f+OyP/+0TVn/bnx1A0dmgHGud5Cbt6366qst6hYJva0MCIJodEKyCxJ5Gok8tOWn LccMXlpQV8I7FPfnqDnOzsb7Nh/R2Gbo1njfzFhXSxJGbVV1c5eYpyV4hkSYE0JQc+4D1I2j e/Yd3Pe/WmE5aU/Sfa2szqsikUeRqls1bIpyWgcnIAiCpgUCanfF4wCry+dVZSbGyPrOw9xq LEfGhamJISqm5GnkPcPLuvMTqKxnc1P3gPUdO5tCcbtxBrYi3tNK94Ds8tY2MLYIfPYcMzxf T1gohEb6sHnB/lYyllWNzmqqXDx3eL19K0GqMs5OCPiYxhjHO5d1JS1VkapXL53cffLy1TNh +CVFUjA73fTo2h0j5IFtmzb+8PXKfcgjJyTWdS9reVSS2fM7cG56Ms/8kCXq8nkry8sS24dO 37DwSauRDc4UGMQ8f25voK2jjpgfi5rqVVe/lNouyhtkMRdC0AgDm5vqN28XiVTVP6epf8Hw hw0OWUQ2D4IGsSXPvc6c2Pfzl6r3E8t6IQiChqjTJc6mhjrI3Wv3aF7Ve4SHoDkIasr2szm/ dY/yLhXzhKJ7JicNtURuHldVO6h353FQVmc3ZRCChmYmi8NMDdXXbkWeNr0VEmNvsE9HXRSd oxpndM87P0ssIw0sVjP3FeL+IGWyGG1qqINEHtr9y5adu19WUJfPan2a4SgzYiTyuIbuQSOX mKzGHuaQZHWLCvk+DnIwmV9lh05fvGVl7W9zZsXm29lLF/dHmbT6DN/rqqc15y2rqh/SuxMT WdhDlNFHx+kYzNOgYEvdfUikODTaF/VNrTN8zmzZcdtfTtynVEU62OkjkUf3H//1uz8hHyxS UJfa0BlnjVQ5gdz6/Y8///LztsMyQ7/pFFncJtt4hMlrzsq0N1DXFi+zYxq6yvq21/d9cdYh 8fGLJQ4ZgqDZKagxxMvqPBJ55OCeHT9/+avZ04UFdTH1mT4W+w9t+W6jvme0teVlE53DSCRS RUV163Ydi5DcqjfRUgUQRK6MsL+rLzPcg6eNLb1CqtoIQ9D0fOmBqbmZvs5SP+fL53REsVFR Re7XN7tw5IjxtYP2JbLRGebi6jLTvU3UzmlJdqGahqqJ+xUVpM0970iCuB2f9Czzwc1Lsovs iLaegbVbQVUzc1z0fB30txc6HD+79/stWhZXLRyCbkmme9cezbO2dpl4+rzIPjXG7+8sTPe5 JrV7TFX9iD4q3sFY/fwVMzlxn1LXFmONRKogkfs3/2sj8tLCgrpgcrTwobGB6potx06ZmHoH 3TPYd1LtBBKJVD6gqWJgF9pKH5Imd5odm+F21Bf72F8SB0dFVWO/PsrH/fot3SPrv9l2+NSt hw2c/tElTQ2fQSzJCbW/roqc3wo6htq3QxLLCAy+ZCPMTEAND91vGR7ZteHQ4cNnwjufZj3y NL94ThWJPKKqsdfAtoqEGZmBIGhyiNNXkxFuq3fxtKQ3dU1VU4+AW6fOG1+XFfdHGE3VKfbX VZEaUrvHNDWOGtsm5DwnsWVvF90Z7p6mRw7sPrRhua5XWXZasqezxTlVJPKEqsZWDduYYsx7 1buXKO7zoy9tP2937bKF+TlVJFK0Ns6Y+wU+xckWG57k9rfnhdsZ7NdSk/65QqprnTL1TM5s ZNDe6Anbx8hHlZbnwv7v/r5hxQmvHNIABQAA6itS7xl8v8c0GVffywMAAB6H2dueb6tsYBsa lC/7s74wzkn39F4tw4gBIp235LO+1RGJd3T/uc85m0gVpQ+hNOc/tdyy6vuvELZZiQ0AAMDn MTkD+QEX9W3uBj2WfSZRH5d2+/SKn8+7txK7FA+W5kS4Oen8onpB9dvvdlkFFL0gAHxTXhxa 5Vp0HwUHAAD4xmwPq+3fHPfqLOkSy2l8Vj+7xFp/t97Fe7FFAADAB4BNrwpwu2Vz7mZMAwDS 393Y8rRAvRXfaXgklXQpvtxQ9SjTW2fVOSOVr77dZxgQXEAA5CZ8ARphHF1UvSQxtyDKw83y UlAZB7D5gDXQ20fq7aUwOADwAWgMPOvi7osuUPwOqx9bfW+bhmXQhyPuAwAAqw9U2Z29or17 jZaprlc6AOJf9HUxKVbIH1YdupSMa+qTj2NzkKvDjT371Iy3rv72dEhuLQGAutLs4KtqPsX9 dCoAbMbz3PDLqj9s1gvplb6GQiN2JV9evV3jul1k+bxqwKpOdT2vsfvg5hvpfZJPyY3ZmRab vvviv/dYZsbUAsDjMHqa8+7s0bUNDyuSOckP8h/bnTqtfPpi9EAfky9eZH213clmv36udS+z qkH0yUAPSL6ktffn1WqWVnEyufAxGenoK1t/NH7YSxUXvcCUdtzXWvnD8o0Xg+UNLYHXS8sT 7X7oPz7/4h9H7ualNAEAAKsfU+e6f88pW8fH1SwAxMu74j7a3MbodnwjmH8Dprsk0V931dca 3ukVmKVn1u4jdSTYbvqrrn1WgiQ6ACQ5qe3etlpdU9ZQd3pamOOBC4kUWYGHigOPT+nei32Q N18lJMv61HXkz8pnL2r6NVLFdYRx9VkeZrtW//OEh9RJKq4jWnudPnLd3iuO1vN1b1uzfa6c 2ae8/kIklsxaKBe+XloeJgCVAbpIS9Qi4j6P28/of2iNuHrPO71E5nPsUy+Piyc2qKDTScx+ HgAAcHsqmiKNt329yzS0olg0+cxeUOty6eDabz77ev3hpYr7PAAY1KTb5pb3zvvLWa7LdL+l vOHX6xmFrf0cAADg0nua8m9u3X3Y9HZk8XxoHl0yVv7mf79c/81LCuqC8qBwhyuLi/siXjMt zxNLU/2LR8ximiSv6WCzPN311v2wfueZiIEFp9iXRFOqvamlwUJxXzqCe+b7v/5p29rtd0sq OwcAAJ2FUV5nVvzl+IOcWvzvUIKXSQS1zue27jh542HkC9kLZblhN0/+cPx2MaND9Gi2r7Yt +cb+b7/+VgV9P7NF2o5DT3xwHXl4xymdB00MyRg6C6K9VJf947MV+kFlBQQAuKy+F6UB2suu +D+X+SoAL0I9LmohNS1dSpkcqX7dltPifnT1Tz9/sdnU+nFpFwCAggEJhofWIQ08k/KlC4xZ GW935sz3hPJuAAAgAElEQVQJbZ0HTZI3MzA1aS7XNn7xt//5/77TDVwsLQ8J35xgvfZny/CF 4j4AAPR3NEVqrt77yxcbdK3vJomf7+TaHTyhYaDvms+RnGRnt8TH3Dmza9Npu1JWNw0AUa1a iy1KG376dqXR3dDC9kX6/i143F5Gv5/5vk3aFwMCyuY/rwy7dU3n0K+XIwlUrsL/ERr9te5c V997XG37xj160awWEgCVYakP0WcCmtlcPuDQC/yuXtA8uu92lvS1lY78KE/kF//88x/+c+8d sbjP4wJGf7zF/psOcnYBJjPV2ejArxpmTymdFIVV1phke8fswB5dw+3Llum5lL14AUD7s+QI szMOFWzM+8xxU/ksOchML7CSy6MBRXEfk+Ec4WNv/VRG3A+8oPyfX/71n7rOFa2tAADQi2+K cdz2l5MOBSkNHAAA4HMBm1rqqWN6x80htVvWUN4jU90NO9Uf9Df0vK9K3AB8NOK+lNdLy5N4 afUf/qT0i5lbdusABEHQIARlOh04ev1echpJIlfMjuPSHL3uWRpHy/6s7+tr9zdS+vtpdG0h bmbJRRV5RChRc/Mha4e0Zprks57oCxcOr9ymY+1UJv5kbhJXk+Bpq23s3gHNP2wAfYIMo6Ob T199VFgzqWC5h9j5SHOF2XWVlXuO6hp7F/RA40JBe/QFm+icylYIgqBxoaA9/Mw6w1uhgTXT 0q/NEVPjUFeVd9k+gaBBCIKguWlaTVOs7da9Hjl4plQ7EgoEpY5HNXRNzUJrFFMP83oECZqq qOsHtu85ccj40mMiJBRCPVEevtHeMa1LCU0vsTNGd73V0y4aSwDNTo2P8tlM7sjE7JwAglh1 iU+ddE6nQTLH2MWQM+08717/cMR9iVsZiSFXN+3VPPXlxahuar/oQz5pNv38wY07NBzSMony Z+PZdW1P7/x83Ozq9tV71G/bxrdBEH92JuOeoV9SXjsNggSzzBF2oNmOjfo3k+JldMSWqJvX 9FQP3M4AE9CcKAf3LI3cFHHzly9/PhOQUk2WDH+GEGmov2vZelUzm0IIEgqh2TFs8l33e9ZX Y2VfGCERm7yNli877dZU3CNZ3oJZCBOA0rh4zixyXqJriYgyP/j9poPKXp29UoVmlDzdYKu6 Sh8VU/ZC+t1iO3ONLauPXZU3tAReLy3PZJ75uoOr/7pB2861XPwhNcfpntnFA7dzJyBIIGpF rayNtt1x0Du/lyNdSnMzk8V2ykjdG1YR9UvPrC2AIEyajZqpocW9+eg0Fz26ofHD5m8Peuf2 ccWGRvunGu1ULkVllckf8q57EBPorvdo/skHLif6vuaqYyd37bMvKOgUfXtsZrIp3GD7nuOm luG1Uidr/S3vaa49elb3kE9XH1c0C1xqRxJ67zc/qrrElPYo3ieWkJanrybG9a7G4uL+9Fhp lr+Tqar7UwgakXw4Rmlrctm3VfmG69MXpBkIgiDh3PRkk6eNlsYpk8B46W6iZCc7aG384p9/ /uNmk4ylivvTkx1PinxMv7ua3cOYtzw93vBIb6vmBTevXNIUBEGQEIImsfHWVnqnDt1I6IIg 0Qg4jcnxJhu//PzPf1hh4rpoWh5W12is9sqzYYuI+yJeMy0PNqvc3eCPW11z+rmi50Wj5NYG 9K4tP3+LQGWmdC5pyIou9jbG39306928heK+aAQNUWo/bt/0xZYr/kGlDAiCZiaGi+5sOaBt bh3V/PvkjadkxdnoHdllYN8CcefXBnN8ONpkxV5zr/wi0asJc1MQPtThzL61u85qe1VJ281N t7cW3FH/csV+64JiSVHg6fGhQpudR1f968BF70gCBAkF0ORQsfdZR3tHma9CEKe+Jfbm/h+V zVKJ7RzJ4p4eg7JNzNR3fL3x1GGLpG7Ruf6G4AdGZ7Yfs0uagYZFRSNmqYTKIPOt3x+6m1+K FdkdmRypCzm1acey//l6r+FiaXlmIagrycLwrtVCcV9MtbeZyf6v1xw+fMy/mw6mIAjC5/mj DbZ/eSaphzkiuiXPAQLrmfmJtYdMA0rLGBAkqlUbckpbdcPX69Q0jaLaZd5FeE2mRwtT3PV1 dp26ngtJn3Kyusrjzv/w00nXxHLShPxfGGbFoxSbvQgTi20rftK6l5vWBUGsruE0E22f6jLc EDQ3PdCc90Dr658NH+U20SQmQMHtrUdXf/bZOo15cX96tDXV3euG9vVcaP4B8EjfcI2T9i/7 LnrlF/QpvPbF7KlOsd2AsLixbet2rfPu6dUQNDUyWHBbOyijrJy5xGH/nrBGBtMsT/pkVuCZ kKK4P9Jb3+ClYpbCahEHgz7MDbv07Vc/fX7YwCOzBoIgaBaCsJk2KtdM7B0KJbM3O9H/PDjs 7nnVBxjWkPQ/WqxhbozlryvPWKYntLysmsenxkcl7lvcUNP1ySZSB3gigZ7NanvW7Km9164w r5kCAACUFmKB01E935RnrQNy+hOLTmkozoyyuehV3D+w5Pze1RGJThe+0nvc1UcX/cbjcZhM MgGHxRLJTJHcxqYQ6r2O3vRKfVQyIHeujU1ndD2vT7pz3rm4UjGzeE6EjdbBn/btt82ubSMN sDhcwOUw6RRiP53H4wIAAJdUkxZ/deOXp0LTK8UyIpuCr3fZu0f7tk14BQsAANgA1Eeb3nT3 Ck/rp7NlXrHnshj9HfVP7xj6pFUqahxVjxLMDn7+nfKlqPrnHQM0JhfwOFwmhdhHZy3t1QZm Waibt7mJRwOgcUCBq47BCVUNyzjRM4Y8u7Nu7r6hzYrf+aDF/T17Vc65P6ygMqSRZNMZnYUV Mbd2nYsurJGPY3OQ6/m9m39VPR+Ka8bRmGwuAGwWk9ZHorJ4fB4AdbG2btc0zwXjO/t40rjy uBxGHy7e6ugtlKtPsaSrAidPVxfj+2X4fob0/CaPzaR0VmVZbLjs8yymFgByI/aZ04EzvhlF 7TQ5PZtJp9QVpkWirviWDjDE+mVfbXf6rV/XmQc8a8ZKDANGH6kHhyOSybJrFJOR7n1z5x7H p/10sugTLoszQMJhsfg+Gu1NS1K+prjvr/3NcfeGvBdMkTDL59HZ1FwvvevuAYnFAADAAqAu 8rKZu19UBllhedN7W2uyrA28M2ueL/kBRB+pI8V201qLoIJcSXQAYFBIBAKORJI1tARx/wAS qa7hkEkaYEsqu3LZDCqmtuy+9m50QqnISSruRbT25xuQ11CR5TKzwGFS+6pTIj0NVBxLBxZm Qnp7cZ+K70gy3m0X8jSrjSF7DpXLpFJrUqsCrpyLpTcQAQCg+3l6uPFRs6S2agJLPPniUr0x HkYntZcs7lMBSHI6b+fhn1UldwKWy2ZQMTVVAafORtU1NAMAQBeuI/zcthshT6pf0FjzoaH1 9WW7e1/Rfhfi/vXbWug86exzmVRqLx6HJ/TSeG/yytc8rxT3bxif2Lry/KMOIp3N4QEAOKym lkqPE7/YJJS1v9VjBRF8LmBTEq/vumbj4flc9kJZbti9M6suBpGZBPHfNjZHVMaZSBmQieeL sLOObn6OaSTSAIcvyVTCYdKxNYV+J9beiSsrIADQWdj6yGSbRWpeY5/cVHBo1L6cpORgU4sn bGkc23Lq0Sqf/c+xa8mlFXQWBwDA4wJ6b6zpSQffsDjpKxV5dx2dPa4HV8nY5bIZ1M7ybL/j /2/P1TcT92sjNT9beey6/eMKisRRJiXGy9rB8mZcs+TRTlWoo5+NmUN+by+TLxJ3eWxGX8vz TLM1a7YYmS9d3Kd01ycY/sPQMSW6bEB2K7Bp5OokH2f9bWdjWC0kua80+mvpbN+7+ww6Ak8g 0vkcHgBsGmOA0iuKxotQJ3s3c3RGD5kpMyk0YsOzDNOfVmk5iMV9chdIMNSzDX+Y2yG/BRkM SlVFWcBJvbjmFoWshY1JtjoqW/f8cjWyo5NIZXE4AHCYDFp/L4XFf59SN2AzGQP9vQNsPp8H FMV9LoNCo1LITGkunZKsQNTpn428OomdLA4HAAB4XGo75amJxpXgiMxWAABgEECNk8FV74cJ 1RQGV84QrbWhNN7ilGP2C6z8tLxTPk1xP/3O6hVm4RXY/onpWQiCIAEEjQ+lmtt5RTrnSVQb 4mMP9wCHwHL5Yq2zs9NsPr3Q3zogs6RtyXmXReL+uQchBQTpb7yZMT6fw2BxB6WZNAYKPKL9 HW9n8IenZapZCmaF4zxOjd+D8MzIQpp8vz3EFneN//zLtvMhkcU9/OGJGUggFE6P8QfHJqam IQiCBELBVJufmtbFOzci5zX3gVwnh2sG28yejovVz4HWJ9E+56zD2MOMmTlpvUahUDg5xGlP uJ8QERmjoNDyegTxGlvWbDthHZ3QxuePzYiL046MDY9NQ0tglkNoiVTd7FGIb+VDvaUx/vqb v1H2yuph8SGIWJgYfUPnTiNEX7AYP1xx305v58ZTd4r4fSOz4rkWzArHuOxqj9uOIe6x7XLt 2XVtsRdXf/ZXVYeyzJbBobFpCBIIheND/JHxiek5COKTmtIv/tPIpyy7fVw2rtNjgy1pPl6X jlx+CokP5pKed8Tc3HK7qAbHkdYFFQqFM6P89sdmvq6ONoUQJJiDeiKdXQKcQyqBXNaV2Zlp JodS4HPrQVZFJ13iNoQJQF28c90xCzNveHQMsOlMNnt4Zla6RkfJ0422qgdsfDOa+yWGockh wGUxOAAsnt7l1by+uH/N7oF/2dCwZB/NTnSXRgbcM3B4CkHDEARB1ObUSJ8LthHsYfaswvJm t8b6xkfFxC950kXi/gXUDXSwTHQmRwGXwaKzhyekhpYg7gc4aa76/HRkDZY9Ia6aKhAKp0d5 rHzP2/6evlIna/0NjTSP7LXOYo9IZ2FudnqcP9AXb6rpG/+seEFSot9F3G8Ovxfs4fqwcVjy 1ASCIEgwOz0NBlhJ1/2SKhM6IQiCZqcmnttoeIQmpWFG5id/dmJ8qL4q01blj5stlyzuNxUm BNsYPSwGE6PzEygQCqZGeawCT9/YmIRKCIKgWQh6Hoxyd3NOawBjMxAkDs3U+FhPRc99lRU7 Lf/t4r7/pT/pJHbThgSS4EwNsVgMOmdwfPxtUrq9WtyviNT403JVh/BC7OjkHARBQuH05GCC i5mbu0+hYu6gN2N2oj3Vzd3oyLlMaP4JC8QcH44xWaHrmlDZIlLdpWWcWTzZZE2c+tin3hf0 whldtIlJSVFgUWHbZ04mnm7ekQQImh6Hiu6gPCO8nuLl8jzNTU2P9fSTHplapNc2SKZgegzK NtHdrYYwC8sC4+Lpnhp9kRjkf8PYvRviiXog5NVH395jW9LaPzQp3VaCqVEuM9dB9YLhG4v7 unrqxw7cyeKMzMwJhBAEzUy01Bf5a+50L6fyRc8Q2F31qcZ7bTPa6wYmRc/bRLVqWyNNjNXV dr2RuN8QbOhse9v2CXf+sS4Ezc1MAio29tJ6y/tP07vl2jMrHoWe3fLFckO3ho6OoYnxGQia mxGMA+7I1OSMAGLX1T/xPmAQ0UpgT0hexxBXGw69eOH8+XlxvyE4Osj7SlizrF1IMCuY4nKZ 8W5eSYlp8oYhZk916K21f/9a3T3qWQd/eHxK3DN3ZHxy4dPHd8icQDA+yB0Zn5yZgxTFfcHs 1NQwB4zPSYJBH+ZGXfr2pENEYfXwuOQJ4sx4R3iAj+8Vjxpxl+TM6OD7pk650sUgNjQ3NMgq j3QLjUutfJ+1Tt4hH5W47+h47nY6RTb7eXcJIfj0duu8nEYyAADgyrEhJ3/46dftuw4cV+Tg vl27N6xRcyzpbV/quTNK94ucMIeLx9WR0t50dfS9UvsGpD+IGb2YjMs/HNi9fdOeBZaP7D28 e8PyPY5hz9vlf0DnRKBvG2ncC2+h0F+SOpxNbWjJu3VoFfJuWFl1LwCASMbF227dpIuKfVwr elTAACDdWfXAobWbti+wjDhyeM/K5Xuuh4WWyifhrnqU7my0wSi8qIs+8HYlOtuS3UJsjU0y ORRme9TlXfu++W79idvBHUw6t9Bb+7ytw6OMBdH+oMX9Y0Ym6OQyBZ/ZbfhGH9V9jknP2+Ti 2BzkamOuczW4CrdY6nCAzfW2d7x86z4O0BdcJT6+4uDoah4nVoervbRsbB1RmYrB4rEZ5Ka8 uo5eLAUAbElHkNbXP2zesfvggqk+sHfn7l82nHSuoHSK0m6wKYzO53n2hvo6qpLWyOPHzzun 1ismZGcQCKXxMRY6h5Anjohbamrr3w6spuEWJCZ+fV5P3E8K0t1mmklunHeJCUBloJ6px/3Y fAAAoAGQ6nhs78H1m3csXN6HD+5Z+dUe88iI8pflmH8ZbBa9vSnv3m09HQ2ZWBq4pGfWyXe1 BHF/n7GJ5e1kxcoe9J6OAvNN5g+LUlpEX22J1v6LulVUWImi0EwoT0kyP2AQS61foOa+tbhP 7e146rr7n7t37NxxaEEclXcc3L7xK6P0wuZ+AFrLEnxMt+r5dNMwilJ5Vbzt5WtLTcvD7gWt Luf37Nq2fofywlvjwYObvvrqtG9hVhcAhNLWONMfjvhkVmEUN/GLuHj0tc0vK6j7e4n7PQ25 oXYWBrIOXjZ3TigB4K2EfQBeQ9y/43j1rEkKnsmRPr1q624N0lpnFVfa9gYJgVj92NaIqyYG 6rKD2fbj3/YbubkVyjbsJzVkpN69oKpyQtpMS9/4bhazizzfGQCtsZeR1o7BYY2Khtj0AUxZ TjOuv5cJqDUpmRab/7Zy127lowumevf27Yc27bZ9wmSLO27LafbT/V7rUUqDXDmDzFvaLn6h 0rffKl1O3LLzcsxWvDEOYBufXfv+qEXYG4n7jZGa3xt5paY2yVkOuOtibf64XvwfjIpoq1tW F52iqYAjk3WdS+kmpxoiDt64s2Rxn9LzIsdp6w50VnX5gqd3tNqUQrT6FofGqm65tHiN/lrm ZvduRrbi5TPji+iOuXTdGm3xSHFWuKRW8oPDv+q7icR9FqG51Wnrtu07Nu5cuPn3KyvvXLbs QkBZG0auj8YkW3MLw1vOtQTOe06y/5vIi/sLL2dFuhsecMzhcOcPVtCxoNxK3TggPK0ZAADI HSBJb/fWHb9s2bcgOIcOKu9eobTHKqmhhrxY9++ET1Pcz3FcfTi0Ds+R+0VdYGXvE2H/RHzY Gaqwv3Hq8KoN+9QUUVFT279hhfJV/9wyziLd/xbTY9BAY4Lr5av6sh3eDSxsJci0ao+6YYVc tWLHAstqamoHN2xQvnrVr1xeW+ohtj/U/Oa0T3YHFiyuEgiFgpG+UMeLRsZXg58NQBAkhKCW 9LsXTfSs7hSyJa3aSiOttL9a8aua2vEFlo9s26CsddUkTd4yr0eQoHnU2Ncv9+2SlkPQMLmj wuxniwRsOZn9Ig19bd1f/uOvh+88I3YP4ysf+1odvf5oCOIu0AI+XHHfxeLoCZe8IWhY1meh ABpJ87Hzc/Eqkosju64tA7Vm9+2MGvpi6Z6GaJ2FHjv2elcTOxdcHW1NK/U22OnV28OegiCI VhGVaHXsWPhQL08xWON0TD8Jj2FDkGAWKre9qnVo9cZFlreq6v71/1I2DSyoEC1voRAa6cWk enuYnj4438zwlldKgcIzptlxAb+rIfCWmZH2EXEzdTW1S85JdU1Ly7cvx2uL+4fQoenpcg+f +mvjQl3O3EkWv5jyoijE4uTyn7Ysury3rlPWuXEjg7a4gZcihKAROiYlzt1U79B8b3qWvr4K T+CWIO7f9zm3Tfk+rY+rKAPj4myCvd2cq8X/rPU3sDY1vpKkeBuam55odlNxCsuO71J0963F fQEEUXLunT678+eNhxYEURWptv2HdadcHTNIEDQ4PV6M3nvGI664VnHiBoj1EWYrNqOWmpaH lZ3gaLB9+UZlNTXkAuN71q1DGjv6t0HQ3BTUhDa18ECF1ipmOhnsGSsy26+M8v+3ivsjDGpt ms91tTMnpd4ZaJ/2yaLxFiToXiqvFPfrYnRWGYXX1pClt+MZCMrxveXp6ZlPWOQbr2GyKjLi 3lm5v0Lb1u7ae1AvVVbcn5yb6u2ItkcZ68q2tAyrKpVb76wXyZ5eFwxtaiDOgu3MJ3X1Eonk UWhucoQSqqmF2L12x9EF84xQUdn2/fcXPbJbxB1Pj0HZJlctvO7Et8nuBMyTiEe3jJzbId4k BEEQ9fnDxzZaGtFDtCHFGyMm+qqtldmbivtXHVG2znL/Fehur310ZqtzCZUPIAiCKLjKx2ar NQO6GCT5591jL4J9b91QWbK4PwdB5Cc2Zp7uwakL/gcimBhihp8080wKLJerEsCseJSA0j58 70ULb3LhfRS0JKZ5Gm+/U0vjKT7KGytCO9rckor7zCc2KN2d325auPmRamrb1qw5Y+L+tEOu A2ZPdYLtlqNWz1rb+UuuKvDukBf3F14e5sdc2mYVmd8ud+PsTQh54G+Mlrx02fTA6+rx71bv WnhnVFM78OsaZf07kdlvUHLjI+SjEvfd3C/cy5X/qry4312C8Ud++Qvy5DkT60W4a+cQkPqC RnzNrPIyMHpam1PcHO7aiHsyN7c0Mr5g4/6ouEOkF9FIXbH6XyKQ2mpGi1m+Y2ftlvq8nSiv LeVEeLhZGIfVAPByyY5Mxmfd2/6v03eio2uogFKPzzbf8S81m6iyanFfNABi7x5BIPeq6y5m 2dra2jn6eYmCqlX16ImfxR6nGtJbSvsAUCofpQXaGN5v62+Ltj1xdMfy5ZtVtAxj/n/23jug qSz/+9/n9+z3993dqbs7JYw64+hYxz72MnaNYqRZQBQBsQACCoQihN6bgNJEQFCQjoh0FQQE qUpNI5WEVA7Sa7jPH+kJKKgrzs59/af35JzPaTfkfc/9vOupjYGmJ2ydA7IblT7ySYv7apbo wIcNSoHgW8JO/oaOy6uTi7j2hoebl5HzoylqrM3wcHO+4HIPgEmCemDr4ektyX3/wHb3FWtH l9w3RthU8Mpf9euVqsfPGk82zw6OrjdTX3ZKLZHZHaAyPtzPWVzAEo0+a3ThqktYfoGChSq1 iVQQjrlmKy5pZmlpoG9oE5ja8OIds/JMU9xPvXnqd+t8msw7LQriPh2AOJud+1R3qutMtbzj Hj99mzPzZLABqMwO8/WSqcrI6MJll3A519+ZiPsWaBf3PMVmWO2Nz+zXXLpemFAl/GhdrNYX Zz0fCP8pC6k8OdN2l0YEvRyneOm9xX0S8VWi3eo5B9V0dUwmvTW6oKNKXuI7ACjNve10YuG5 MCpTSRetSX0HQ10WETyzPbHjwF6kzoUpZjAk6+ULAgCvHtUEnfjsaPjD50otN6coGerK8KHE fQCotbmPbrlII7t0yeyi2WXvWxlNHMp75d1+q7iP8bdWuPru4j4TV1N+x+W82hE9UxNTmXE+ vnmu6gUFcR8AJpZUmehvZ2svKnX56lXDs/q2LjGlZSKT3E4ASq9rIS0dwuLeqGe3l95NuLTy +y2nz1ywmGye3V19kku5PJFO//Jh3Q295VbFCptXQdzPuLrpsp23l0LMADBxtaVoJUNdcSBv E/drb6svd7hXKn9VQdzPCLlw+ZKOT7LCox0mDpSiNQ5aOs5Y3G/H1aZZL0UFl1YrPSIBoOFB 7Q29pZaPS+Vf26kO0nDwjfQpnLzG6iCN85YYiztKgZBfgWipoS4TW11qvXTTPg1VXdPJ5sUB jb71sJmo8M5Akr2D61XfFDkn+U+Pt4r74gT90qdDCuI++SWIRq3bobpPy2iywbFDo70TnuGU TZ4/Gv+d4r7QUJco75GnIO7nW53XUV93yBAzOYEJj5vb3iFHNwRxXyQlhXtKazI2trBx9Ust kQigL8LOX1Vft/nUFC37Jtx/0ib/o55AbL6tvtThUQtzahF1AoIIGQ5njE8ZW+fxoAkBRLzp qKd/6lJErrSuF/kRV9V/2KKBwVhP1rJn+P3kavmW+QTBPXU1t9zUt1navpURHoGRoHH5Rk1R xdP861eQ3y9cuuz7QwFPi+uyMyO8dI+FNUGQsjbw6Yr7PtdUT0TUK8YsgKDcUHs/D7eHchFz Kl9muy/XTMJRlBIPQRAEcWgvsx1WHIvBUSYJCp/7Mtp0BaYBxxqEIAifeyPUcNOx+9DkNQkZ H4VyLc6eUF+vem6q5X3vaStWNkc3vepFxk2ZAuZW1letXWJSm+W9WwXjED4383aAuJgjBmNs fsXGLSz/ncdzeuK+0FA3K0dOmVEQ9ytzQizU523TxGDQk/XZKzL1rc7MU0DHVWXclqnK0tLa FO3qmdbClYzOTMT9kHPbTiRDyjnSKak24QGe9kWifz4P0nVGW0j+KUEwMth6/bBjWPbtOsVL H0Lcb0mxPq63Z7eqyRRrJyInv54JQZzhgXjTJWe87pYqJZlnk9/NUJecHHtNb8MK1QsYjP1k LV9PyC9uh6DRQSjHVMfM+2qMUsu9JCVDXdm4PpC4D0HDoINaEBzg5SKKzNbW8cIFE0xgXBme +F55t98q7lcnnFjnUiR79d3FfcHYCKfy7g2bixfOG5nKjLPxiX3qBxXEfQgSjEGcivz4UB/p 3r9kZm57LejBA6kdLflZtMs1DT2J5j4pY4M9LQH7NdTV9526Mtk8u2Awd3KbaSKZdKQfyr5k 4XPXT/5ho4K435rpG3Rh76lU+ZghCIIgUpKSoa44kGmI+xbBfgHyVxXE/ZZXxUHH/3k6isSi KnyYlBTlfE1rxuL+GAQ1J5rZBwUkPFa+ONwLPbho5nNX4eEiqzQq1dPwdBrEmiyzP6s0Ku7a sY3urxjKhwPKfGUNdUmJZtan961BmU42LxgMJjKx+JX8DY5FKE/FbDoTx+DQZtDHj85bxX1x gn65t6EUxP1nPu6X1BfuPDPF4PhFZ1Uqmzz/V/LfJe63l+OSzi/f5Xw7r2HGuXdmREdze5Gf /tpV2q4pibUsAACL3FZgsVzHPia0cPotT0fcBywKtsDuN5S2PebO08YXqblXdy5SDYp80iI+ IZMzQ2AAACAASURBVMwCoMDvmI6V3c170391/MOJ+6D9UXGKv+65uOp4g6M79VV3bNPV37f6 XFxFvMFxs+CAezXKn/ikxf2DxhY+GZUKlzgvcdUBqB3OSYVKJ/ffJO63ik7u4yY9uX/RycXD PEE0AgXOSBMz66uJiue+5SCUNt+9sGiHy53idxGzAegEIP+W4e7jpxze0hAgkFti3bf9fPBy QkTxOzX1wcT9TgDyvNVOWGEik94c8oegLPKs3nHdE5ZJOImkNZm4z6e2Um8ePmYfqyDuG1vY OWQpikCTntw/4ZgU80xxpRJKkpMsdunG0yv/Ayf3yc05QftWXgjISmt48w6pf3rX/9J6Hf9W RtuHOblPBg2BF49esPFLK32zQIZ/XB9/af6+gIyyttk5ua8M8Ul+sLnWxt2n4rE1pPdxEf2Y 4n5nS+Gdm7q71p0NTarFUWQuZFpuMbNVEvcVoVNaHtzSXvq7tk9gxksmAMKT+5Gn95pY+QY/ e9O7PLQX6dmuqGWn7+XUkt5+G56euF/qjrzq4Oucrdgu471O7k9H3C+NtbxqaeASSwc8hZP7 qWff4+T+ZtesiilP7mMmObn/BnG/Je6cqfU0Tu4T6+v9dyKNgoOzXk37Xaw/jbhPbwY5RnvV HLzin830/a+Pw59X3K/ztjJ3MvYu5CjX8GGh59wyO6mrZ+daLvrZjbtn5WNron93+i1PR9yH IAjCpdq7XtJB2eUxJgAh8rShvt3Fm1Uyv2VxZfE+V/YYBjAg9jRz6nw4cR8aYgoI3lfs0lJv uIZYGa1dqu1m/MNqw/CwG65h192OOT2b9EOfrrjvbo1EBZZBkJyW8oaT+28S918zmgq8Nm33 q5j05H7aE7/Tm3zbhSf3yUWR4Re2bg9iELlTp/8QjEG1HuamTuYBj2f68okYbG2yneX+A9uD GO1KB8xlW4KgmodOJ86dtDif+I5NfThxv+1ptOfVgxeuM6E3hfwh6Ki+F2l54Mffr5eRxba2 U4j7A098Iv2dFcT9IP3NqrdfU4HiEWPlk/vXLIwtHijKdf/pk/uFHhcxls7elW82AO0eGShy 2TblyX3zdzm5X5Di76h70jv/NdT3hoQe40NQtcvUJ/fN/+Mn95UZZA01R1/duUXPNSW57X3O L39McX9sdJD51Bald97BKa1WVipuy/K/fl5J3FdEAEHUZyHnjE9fOOVX9RqCxiEIglhV8e6Y Y5qmhT3s/imncHy4jxp/6tzVQPfUtre7zE5P3KcV3oxFa6jF9kx6cv/au5/cf6u4T8M+i728 WD2kubNd/rYzUB8eYPnuJ/d9vcJSlb51BYM9rOjJT+6/Qdx/w8n9AYWT+3lOng62egEvemRS cr2RP5O43xwV5GSvcSW9U2rj/CflExH3b+puuHwzrbJRqJ908UEnlUzEE8l0qaQ2HXEftJGx UZcWajlGPyzskEstDXhsNoNKxLfTWPwpUuBMBZfNoNMp1A4ukHk9nceivCq02qhpHRb0CA8A AEwSSLmkZoSxDi8ky+W1BXwum0Uj4ok0Bpsrr4lNS9wHHBqocj+3VeustZNXosulVfOPhROe yavi+R5qaCsb+/tkaqdskHw+j9XRjidRlTKnf0BxH1Q+eRCss9rQ12jxSh2Mk4PdPbtT3y0z dDdafhAdfj13EnHlkxb3N2vpWoankjtY0jQIHA6+5EWC9Xb9mMLnSjn33yTug8o7dp4mmnoR VEInXzIBXXwep6M90frAVTt3P3H+65e3zxsaGKhdSyV1cMUZ24F4BnEEEr2jkwtAK7EpwuhH Dac7ecWKy5vF6qAQ8SQaW7S8eexOJoVAYcrmCu8CgMNMvmpmjtb0lCbe5jDpHTQKlSW/cmjN HWFquw19XBMneTwzHR7YnHR2871ZJbUMZtLJ7YR2ApUl6eA0xH0AAMhzPWRlfc0xhSKTTFk6 OCQqgzlTYwAem8uk4CmKDhNc5v3gy+bnjnmlS7YkNiMt0mm37u02itDnlsdldRBqnjwwX3HQ Ilxe3N956rSe4Y1nJIZ0BvlcVnt9+c2TO9wS5XLu7zF09Uqrl03xzGN11GTFB5w94vSfybnP IjU9d9+uaRHon94gn1oa8NidHWQ8jswUenI2F6ZFGe43S26pInHFejYfgE46KcHPQPPYjHPu swB4HmWgYYX2v1lGY3BlZ5DH43ZQcDgync3iAgCasY1RZ9abRWRXNbJklHQ2nZbj43/x2Pvk 3K8P1V1unPWoTujcC/g8bicFR8STKAyW1LeZQqZ3MOXHhoN/Gh9rsn2tXfFT5VmZAR9T3G9+ lhhqu/dsCJmFFdUmGue4i+svWsuJ+zxWB4NOJTOkafQBAHwGtjPvsoYqGhNZJEl9n+O454zB RZOwChprkhkkUphMNh+QK16mXtu8xjQ4u/Klwp7kMJlUMoFIY3aJHb+nJ+6DHHsnN2+zSLl2 eWxmW8XDIOT/v/0dc+5PR9wHZRFOgTbmzgU0Ok8cM49Nf/U0y3zZsvXvknOf2lJ198y/9Vyy 7pazZPcxj9VRmRLkrrNeN26SnPtvEPdBfYQzxtPCPVN2BvmcTnJdYabJL0skOfeFaeWPmNsH Z5XTO7myGX54bE4HGYcj0zlc+c0zA3GfRW8nEbBYHJFAZnBkV9JH4P3FfUAB4K79jjO2HvGZ VAZLdnD4HG4njYglUpncSbftx+GPJ+47emBsk+slv5VHBgZe89hcHhiExoQ/Rqcp7kNP48zR 6PPXU3hyqaWhiXFotBdw+d29gzPMGCsYHx3q5XJ7h8ZG5X4WD+OT7T1tLutEixWC+rgYb/S2 KyksMDg6JtPyxMRYPwBd3aB3SP6n43TFfajjYSrGZP96g9uvy6+prjC0jY2Wd70lPY2JMt2u Ec562TEqY/02AUFjQ72guwt0K1iOfkBxH+oSCNJtNTHOJ/acvnh6m3H0WJr2hh1m+lr7zOzM Tt2e3I710xX37S/u3GBxiwWYo+PiIRNMCPp7KgOvuUX6yLriQm8V96Gu9po0g2/0/Svz2oZl BaLxod6XGUG+RnuNskQHvXl1qUn2ql+rR5S1sIek60w0g138Ln7vMAQJIOhxtLGVjUloGr9X bnkLxidGegGX390nSQ89MdzD6+kblM8VPj7SkvXE7+wXulkt4hPmgrGRQcDqHlBaOSX+gRir nZiSmY2hGFzOnUhjLavywc5+kWXw2EgfYLHYXX2D4pamJ+5DxKLIiMt7jkWympmTLW/Qrbi8 38rEBDTU093T16M4Ok2vin1Vvzpzu61DJGn1U4frnVBnb6YU4ofGIWEa/X7Abbhtam9lppBz 31t71SrbxzWkbmlS8omJsX7wOMgu2C8oQZpz/4yZntax4Be8PqnzgWB8dJDfkWJ2LPBe3n8o 5z4t28kPY3E6pJrXNzomTS0NTUxMDPVw+aBHOBpjw4NFaDXviJQM3ICMdjky1F9bmXXtnXLu 06oTfV1PnLZ7zCO/lr2LTkDQUH83H3T19A5Dopz7tt6eHhm1vTItjw2NkJ+3Bx/+5f1y7l9x jXLNbJd+w/R3d/O43C7JPhobGejrBd19o5DM2IyPD/NrPPYbOoQFFr1PYo6PKe73DvU9D9iv G5xVWi1a3aJxroxzcteXE/cFYyMjvTx+7/Cw/HfbSNudcIytllFCi1i/xucG+xtt22T7tLlj YET6BSqqmc/v7h4Yg8aHIFyE/Xl7K8+Mmu4BiWsCBIkyxXM5oGdwRBTU9MR9CJ9TFWO99Zpc uxMCwdBrbp4LyvDsO+fcf6u4D3Gaq1IMt1/LaK1hiWOeEEBDrxtjTYzeOef+TT1XezvH7N4h ed+LPhYx4fyKq0EPUuUf7L1Z3Bfm3N+pe7uZ3DUsvecIRvu7GqKMDPX1pTn3qZlxHo6nDMOe 8vt6xwUyW1AADb0GfAB6B+X7MgNxf3Sor5fPYrFYLG5P//DYR03I/0HEfajqoZ+LxRHHGM5r 3rhAZnULoNG+nq4u8Lp/8M+h+n8a4n6bv+6cH7SsUhNeAAAA6KSAFOOTu1dsOeMu/Vk7LXGf x+9oJd/QObL1xCmPRLlfxLjcvOvGO5cdtstpr5vZqf5XuSEYJ0MLvxegQ/rzF0tqvWk0f7WR 54OMZh4AwgcS5Pu2qupap3Tkf4tTa3OzbXYt3WkXWlgvLzVMT9zvYgNOcfCprXrquw9oX9o0 94RvE6VZXlxj0e+HWamp7zhlmiqrblNphGwf5OIjJqHhCiLHhxT3OY2FaV57l2xe9b870InR T4ryY67u/tvytUt/0QnOzmyeRAX8pMX9I9uXz91z7LRfGgBiWbqy5L63wQoDv3p8s4Kr5tvE fQ6z8GGUw/FfzaLb6ZIJYFOxVd4HdulYOUQ/pYvb4DJK77nontx3WC2gWkZ7pVKxmV77f1mv 4eiTXAMAj0drIoccP7jp5BnflGLZlrAPH/pf3L1SzT6fJjyd3PrkfpTROv0YsszzCDYAlTHn tp01wjg8kD4aeH7H0d9SzyIdyDyTolJaUr12fKNlmxpb9o4Hlh/Y7D6qoX3SVxJm3h1HnX2r Dqy3SKcyRKtumuI+i3Yv1PyI+i59i3TAkC5YCqU13XPvAlXT8FszddRtefwy8vyis7G5VXL7 oiFaX0/PSNPxgdROmfc0N8bq6ILDDgX0xg4AAPZFtp/Fum9/+PKvP50Mkhf3j5/aqvIrUl0z qJouFr8pVVmZjoe2WNzPqSYJxU46tjFW69c9v323WtvS5p40/w82OyDYzgDpXIClc5WfPr6/ uN/FZ3DoD/1ObTuqYyXbLgCgpfheoO6Kn3RvFVQTAQA8fGl19MWNc0975FeLzbDpACS5oNav /McPK2cs7ncBwGE89XU6dRSpYXe9BrClvWvGNQQaLvhR17kgrRYAwGMSqnOvrN921iMgvU5a Qa6LrcaKr75b+T7ifrX7kS//deJa7gthvXRsXZLhgi1LVY2C0p+Ihu55lNEpJ8+YRLmxqSiI tdFZvMc4i9JAfR957yOL+5jLm1ceixE5JAPQ1FrjbzB/3oLP/metjpy435blHeJkciK4plOm YVrri8TT3+w+HxT6SPryBosWH3Dx4NG956wygYxsL6p514Xo2CdEwOd0tJRnm6/dtM/UJvZJ M5ChPDrOQnfVNqtYFkckX09T3GeVJjhoG508Z5UJJHffpoI4X9Q33/zjLz/p/AfFfU5dQpyt 0a7N1tKYG/NfBGn+sHrRvEX612Yu7vN57UxSgNnvFxyDsp7K/H9rhqeL6cnfzkfjaDyFvf8W cZ/LyAu8ZKanpRNayxG/X0CuSLlnvPr7L//61+22InG/iwc4tMeeWsdRuscdk2tl9evG/Cpf 3XlzdD1K6hvkW56+uJ/jcEBzPQLxy85NOqHPePyPmsDmA4j7fACY1DhTo4PHDpnefCDbX1JZ 7d2r237YYhFXVTJ7jrp/PHHf+PDxg2aO4p+iUMOdu1b7l2w8YJApTlQyXXF/qP9paNi5k2uQ rpkQJNVcBzqhJm+jnUeMfbLzZ3Z8s6sTm+O9fbv3I7y8pPUkxuz0+ZOOQa/E+uBIf/PDGw5a a1QMMpuo0tQ/ExMCQqzhuVPGRv4F8lL3tMX9MeLzBLvLm+Zre7lumqd1NSK/Qv6E/thQc9PT a+r/nKN3vUlG4JqAIEKej4GxrtF5BUfdDynuCyYE/Zlmx05v/Wb76UvmWfTx3lsma/du+3E5 yszp+qvJz1p/uuK+l86ynzdtmGcU2UoXL6mu8bF0p9+N3G/llyu4Db9N3BeMsXrYN8w2m/jd LZO14u3I9Xa5YrDLOq1L/OxqfIROrAy/vPLb/TZZeU2S2gQQRHjkqadzRPuIR4lQSut7HBSs f3I9yvMBBEkTwPR3jNZ7nt162DQwr5ApbHrksdNep5CUe3IewPS6FEd71R1HYgcpQKTw8Im1 6ed+Mo/HVkjTTwggCP/IWeuyvvnVh1On4XgjuJwbbprL/23woLVDmNCknVgbcHbuj4uP30x9 LtKLpinujw01NhTaqn/7s94N7HOp1CSAIHyOx5mLp41NZuqoOz4KFTuYY0IdE+VGh1eTlGB3 5CtUXAMViO2U2SO9Mcar91/1flTMhCCof2y4Lvr05t9//Hzudl15cT/WG/nTknVzt9jn5DeL ZlAwOoSPPm3mGOiVhZeY0z4PsjTbPXfFvt37ApopPNHw9tMba712o+zuZ9R0Kj99/CDi/thg y9Pblkb79uwLaKbKHPUdGx4surZDzcDO+X4TBEET4yNDNd42mhcvYu7LvHdTWxB56ci/v/vi 72svzVjcHxumPSm7YfTbvAP2j6gt0lvjGAQVRZkcNdB19n4GCZd32120lclFNd8y6acJBc+9 VBH//OKvCy+9j7h/eo+2mt09Sb01USYmu7f+ruWbDUG9EARBtBf3g7wNzQJboC4ZH9mhvvvW a7aZuGdlU95HtPzI4n5ZwP6FRs6pQodkCBqFoMKIS0d2/PPLn9fIift91Lpq7/0a3k8et8rl qqu+edbigsGZ8GaJQD86WF+TY4X6bqFeBPmFdA5GhDWrHzE3TyIJzXib4q5Y6GjvN09qkdW+ uW2v7xlsXWXg+LBGJF9PU9wfpeOfhV7ZtPDcbXKNxIt34HWBzeb9i/82Z/t/UNwfB3jWoyuH fj3n/qBG5DY70gcV2JzT2TrnV5T6O4n7w335yZ6Oxur+ORAk+ROtl1xd4b53+UmfeyVEBd/m t4j748P02kchWj8iXQpLxOnYxgZ7sOHHNdd/99kKNam4PzZAKQgLOndwweHrRZ2vpV8cI31Q Afr8YQN97/QKuapnIO7jHoV4HlVRmbtAZbN9RCmONb2h+DB8GHF/eLA2MevqsR9XWkQz+NKS Y/0QNszh2DEDq1spfw5H3U9B3O9kd1Q+u35aB3l4u9CNdj8SufawvpvfjcfVte2Ay6S8ijO3 OL5h2dKl8xYd0NLxSSF3tAPwKjc61GjLnpU/fL1w48ajDv7J5VgAAI8N2kqLbzujL5yUs0bb rXbilKVTWl4pgU2fmaBdl+V9Tmf5vMXbkPsOSutTVdM655yU9rxdNoM/saYoLRhteUbeNBJ1 Yr++c3RyaUN7RycAgFhDvG+jrYlCIjeuXrb05x9XbUMiRRUbOjneea4UAB8AanPkeXPVX39Y g9ykf+85tVPJNYDY8iIt3ueqIRKpKtPyYdT+45a3wx80vCKyAAAsGrHA68TFk0jktlUbfv35 X0u27d0valnb2NG3CDDeKa80sTwzTneRyr/W6UcXFtKotQ9vWK3+57dfbjW++7hEJLVzAXj1 wNfM/BgSiUQe2Ld726KvEQtWLN+4G4lEIlU1kGdD7le2kgEAgEgl3Pc8ri6cvF2b165Q+Rti 5R6Rg6yOia5vEU0kcL6sLgixQSKPIJFIJHLbqgVLfvx+7lrkvgNIJBKJPOeCuaOYXOctCMX9 c9Zm58yCrp6WnUENXTOrkLJaJlfYm46mZ48D9TSPHkb+vnLpkmU/LpZavR63DLr+SDZjOpVU +yADY6iBOiwpc+Dw0W3HLX3uFNW2yT5l6iDUP8u44Xbl+DbVQ5J1tvfw0YPHLWOup1SJCnNZ oK2k8BbGyuiE3CLbpX7yjLVLekEZkSN8BNVUEOd78O/z1+yVMd89gERu0zT2CUiukz0f+izC wnz39/PWIfcfQMq0izxuGRNfTGh7x6w8gFh9J/DqySObJYOz4dApM2Ov3KwyLIfLB6A8O/ya 4abfVs7598JN+9SdUtOfk0FHI7HY30R9129z5i/7de2hyy7+xaCTCwAgNlemxHldMUQipeMo DNIqNvLhq8b2GT7Sacyv8z745U9rNmyTsybeoWViHZj8pF42ARCVVJaQZLRrxY6Dv+9DIpG7 UCf1DKzD7phuW7dh84p9l21CchsB4AGQhda2vWJ8ztHF4th2yQzuRWkfvuCR8gxPZohkUjq2 MVZrtYmTh/FV0wsaUovZXeoGhphbhfU0rkika6jKDUKLt/PWlfMX/4SYtw4p2q/n3V3vinP2 t2bGe1zWFs3v1hU/fL/glxWrxRXruqdlVgpTs/AAoDaWPop2NpFtF4lEIjXPHLcMvpP/iih8 MsahMZoKc3xNDU+qyRQ6qIdG6xzas/OX+SuQp/VCK2twM3Fb7misK4kOdr5wbDvykMxd9IjG cSPX+KRSIpYOAAA8NoNanRPtZHjuuGx8esbGOno6O+d9s2Lzfj2X9JoqCsBX5ty1Rop21dYV qxf/9NmP6/YfEI2Oogsus51UkuR7fOO+w3uEppn7kKg1h419rieX1GNJAADQCcCz4GMbD6xZ uUZxbC6jbxSVE3mMmT7kIj4tjnE4g0QeQiKRyB2/Lf5pwZyfl25HHjyIRCKRJ6xDb+bhAWAA kBt5xVBjxeLlC39egTxz9uaLWnwnqM98GKi/6/eViC8Wrt2iaX7jQd4MBH4mFZubE31e7bdD h8T+qSjNk0Zu8cYHl25bu3TtMTu7xCbRWxrJjk7Hf/126fYDB2VmBaV50MgtIrumWS65DqHp +f3b7uYGoh7J1RxX0CQszGN1UKsf5viaGp8+Kj+QOnomniHZFY08PhuA+szgAP2Nv6+Y+/nC LVs1XW9mv8ADHLEpwQWlunuBypJfV205bW+X2MTh8QHowNWk3fOTb1dLT9PQ0k1t7pKV61Yd sLAPy29iU/gNt9wu6mohkUjk3j071i38/PMFq7cKHWSPnDirH1bdQOgEoK4iO8Bi5461iM8X rdt6wOJmWD4edBBArou5/q4Vi5Ys/HnL4bP2N6s5hE4AmLi2J3djrxmoSt2GtTSPGbkFntqy /fLMc+4DADgAtFbddrY3lFvfu9QNDR2jsitwfNHLU8T6wmi/M8jDh5A7fkUsWrZq2WZJWV2b sIeyzyQojRXZ4RizY9slIe5F6aBOmSSYbFi0bM2y33SveN1/CgAfAPqrJ08jHTFGGtvl5kVL SxvtfreojNzRAQCg1bXk+hqpHkYhd6z7ZdGSBct+k/xxcsLGIaKgeTJf33Tz9bt++stfvvh1 AdLnMZf/Pm+4TJMOXMMjJ9WzWkjkll9XLJr/xfzfDh5EIpFXvVNKpCmKSm4GWqttWLN83ner thzU98h+VUMFtLqCR17HD29b+P2PK1b/dvqqd/JTYY/wleWJvi5mp+TGZs9RjaMX0Xez8ppp 5Pey3Hgv/mjiPofyOCjQWGOzxI12h9ppIxv34tLqDqh/BOJW3bt7DbVr05LPEOt27bEWOtn2 stpLPVFGexcuXr568a4LJt657RA0BEEQIFOf3YtxvSBnjXZYHfX7aeuolJw2xgwtZHkdzYnX lny2YcuuHQflqtS3Do7Iw5JlUhz0cShNeTFBZqhTWrIFj+7WQbuH59RgO3shCJqYgOpibjqc Q6H27Nm1GvH5ok279osq1jZS8yptZyknTRgANfeyLv+GWLT4F9XAqMftSlpyXx9ofPEgyFn/ lJzpL2r3CVMP94SaWoqoTtyj0BBzFOrgHtQ6BGLJpt/EXTp6VO1aKunlOx1OnRAI6nzUNNeu 3XXe7y5nRDBGvXNm/Y65K/ebhGRIu8LBlcYHnxOFtW/DomWL5qusFFu96rn5JAklowkIqssJ sTcXGdod2bTgywVLV4scZI+qoa6lFr8Sqgc9gvGnt83PGaJQKBTq4J7taxH/Z97KnVv2olAo FErngrr3MxL77ckh5KCmJ950OKh1rTjwsoGOdAqPHlW76JaT18ztFvV3nJ7j7mGujTq4fefG pZ+rrNu9T2T1qqV/+fI9kkwG5BHBOLU5wc3xgo7srOw7aWrul1LWKpvBaXjwNb2lKDPIXEtf S3ad7T552csltlJauItELkm45aywvDWO7j6Lvp2Wi+tkDUIQBI2PjuRarETtWCNvvrvvmKE5 OqyshgFJVCQu9nm82v9Zs2mXaOhk2vVPaWp91/xWfeyG8vv2x9b/dvSQcHB2Hz2hpoV+eKeI QOf1QxCjoy3J7Yjqrp+/X7Zmwx5jP798BiQYh+gP49zOqa5dtfSHX9ZraNmmU5vYEAT19fJf VmYGYPS05cYRtfvkZW+ve3V1lBlO9PgIlHP5zJEdP6/+Xba6g8fO6diE59QyegclGtuwYJTc 5HvGQOPQxv0oFOrwUbU9p2xiQ22NLqlvnbPhuJZ5UkVndy8EYR/euWlw0CAy3f6CxlktsfXv UbVdp2yCUirxMsmJngdZe185d9E/3PH0zuPqquIJ1Nlr4J5cRmK9Fj5Aej06XBxlom8gDGzX 1rUq/3fuql1bhXOka3zMr4zG64cgCOpuIxQGXkShNFEoFGrvtjVLFyHmLN6JOqiKQqFQOpYB gdIs3gNd9JZniWGy7aJQKNRRddQlj8Dk5820bggSJqFqb8m+4X/1rOzg6JqYXLQ015z75YrN e9WdUmbmczDM76Y+K0hzNFU/riVvi2xoGxT+qFniRjLAaKm47+90Xq7lM2cu+vporpy/Yt1G DdPAtEIGND4yWBNpbCMcnQO7Dq9V+WzuqnVbhYbQSi64gnGI1Zjnfem8xk6JaeY2tfOmjree VGAZEDQKQRBELotBG62Yu0Q8dELU1DUveaRn17PekF1qcgZZgy0xzoanTqJQKNSBvTvWLvry q0Ub9+5EolAo1DHDq1fvk9k9IxDUWpUZcGXXjrU/fLVk814Nl7T0Oh4EKANFLpf0fl++YNmy ZXu1La/fJ0M900y5Bo2Nj7HbKz2cDE8dlVndhnZBFhf1dTd+M3fz8TOhL2opfRAE9bZXlaGX Llm7bdNOhVmxc4kpbqDKbqveHm59eZrfNd0Tct67KJShXVBoVoOkcD+juSkj+MZVbXn/5OMa Wpaedx9XMbpeQxCgNBa6HD6z46efl61dvu+yVXAxGRobhaozfa3Pbli9asG8ZftOnL35oo7S B0FD/V2tL/P8HM/ItKumgTL2tDuzW/P3X+dt0jlhmVzN6+1jPSu85WCAQol8UH+eu2jhErth 1QAAIABJREFU8tViB9mzXulZ9XwIAkN9hWHnTx9d/vOK5cs36VhZJpN5vaNQa2aan97O7at+ +GrZln1nXdLr6vkQNNo/yn75PNrBUuo2rIZCGdu5GOkZXZ55zn0h/M6a9GSMkewAHtLQPWDk mVDcxhRZ1w4M9zdlOuobn0Ad2Lpq/dJ5c9ejDhwWlj1lZB2SQob6xPenodec9rIUf5MjZzRF M3jkqMauU3b+pkf1kBu+XYw8firwIbubC0FDPAr5aUKKg+4RLTWZyVZDoYztg9Py2zp4EASN D0PUzFuOxrqoA3u2rV/8z7lr9h8UuawfN9K2Tqnh9ynfalvSPG23/uUv//fvf1lg4l/YMlNz 83ejJd3L1wSF2v/7wTU//H3O6vXb96FQl8yc7z8X/hEIQRC1ov6O2SHk2h//vXjdZi3z0OzH ndD4UB8145qD3taVK379ccmhE7pBD7mvuRAE9TA5tVnJPiY6xzWkY3PkKGqXrnlAbMpLEu2P 9Qf1u/IpiPsA8FgAl5sY4uUkMjGzR6Mj0mtacaKLHbhHISFe19BoNBrtgnG9+5jeSQMAV5Gd dl1se+Yak1T8UqrJkZ4V3gtxlTNG8wmIelQFwMzPIZMaCu/FyNeFRl9zcA5NqWcQlURFWkNh gUJp10C3ey+kp0qpLdSiCBdHu0nM23xu38qdQjF4mfMg2vua943QXNwUSUhohPr8ZE+0xPQX jUbbY9wiHndINGQOg1qV4OzvMknLroG37r0AU518fTOdhPqaZF/MtaiMujY8ANTmqqJwewe7 COE/AQAA8ADAld4LDsFMZlln64D2TC1qbKcDAACVQSmKd3Jwnqwg2jXI/d4LhihlB7a5KjUc jZ5sHNFo39joXGUr3zciFPdNgwJvJNbn3/ZEo8UD6eR9MzkPLz1U24mvr7nv6Whvo9ys0437 KeXyueE78bSa+9cd7a9JZ8UJHfmkDjuJak5tqiwMR0t9bdFoeyePyCdMxbLtpfkJwfKLzDfo dt4LGUFTuSohwRl1VfLH3LFlGSlBisWuOXtGPmHi3lXZF0ZZl58QLROlb2xuvnROGsoyoiTN usU9fvKKDpg4avX9QAc7oben6/WYpGrJMWEarjb3vgfazkY+yKed7xIkpYlUEOaoPDohWXlV Si8ByBd2vR6TVE5nl9+56euEdroZnlqBB4APQBZa28M3OPBhRUGYzLC7BXslVXfKbFihuO8Y XxiTlp4sO+y+cbH5sofGsY0VyWFotFKISoXbS3LjryvenyTt33lSIp9Ppq00LVl+uh18w8ML 8GzZM8NcBsA+jA90F+9XWzTa686Tsqy0+FsuaFuMu1faq5YZy11tr8rvh0m3FRqNdsC4h6c3 chRqan8afydI5k7hdic1J6vo0S0PURgtjR2A8qo8P0xuMcjgFxxXUCN/4pjLIGGzAwLdxa6x Dq7oqJJXeMnIcAHAPr0TEKR4g3L2jUgrwIPJjwW/GWptdc4tjynmxTksNf05WfjGQFaoj9DV 2dbJwyu9qZXMBm0lZfcDJf0PS3v2fGbpwMlUQl6svZ34+9TByTMyvYnzNCU0whPt4BsRWUgQ HvSm1jzKuaX4fWDn5OmV3tQ6iYMwte3Fw0QP2TUpqlmxbH1maoSnQocjMyoJYmm4rSQ1SdI/ 9/j0Z01kQKYS8mLsbIUxO/hFRhYSuCKxW9SuZLYd/CJvZr1ozvL1d7NHO4dHZlQSOB1dbQ/i /N0cJxttO2dPr4zmNgobgNaXz5Juihehc3h6RiUZdFJARUywl3DuHZw9ozKauaIeMdvanyf6 2dnYixv2DL7X/MTqyLsY6oohPsmJDZIbdP+EhCLZ9xyobVXZsv2VwT08o6ySIlcfuaE09yba RlLaPdQv4TGv7HawFwaN9g9NKJIe1W99WpoUIFefg59XVFEzjy+aQEYrseKer624v3IzGH4r s4owmbhfl3E93BONdvT3iipq4Xd9BBm8k4ytuG3rpbhbQxOKa6XjWJd+P0y4/6SmuIzWyvJ7 7uKx8r9xV2ZwqNXPH0S6y1Xo4e6fWsbnz+Qx5ofnjybuQ1B3W/PjhECpiVlYbHY1QXrxyeME X/GlmKxaYgcEDXYxG5MwQUKPW8/w0PvVTAgSCSD9DParzBAMxlVaoScGk1TK4M/cF62/h/2q OATjK1MXBoOZypt3pIfNLA4JkSvthIktrZW8cDAxARHys2MDMcp4BjklNYp/4cvDJzBKYzAY p8CsxhbGpE8nRiYmGC+SQsI85aoMf1BXI3PYtePFg6ywyUzjnJxin3W2z+xArqRDE9wXiUlh MXdyaggQNCEYx+eFxQaGC/8pprujsShzsk5jMBiM793kp1guBEHQBAThX2TFTBojxskJE/us XhTlgGD8ZV5Y4ORVel13vt/UCWYoyFHTE6P8T1xJEXQUJQb7iAfS1cn5xoMmHlM86hMCAbcq MVFhoIVF/W/eeNLJ65U5fjkhgLhVxYlhPrLlwrMf1U6igQjGx/B5N6W+tqKyDYpl++mdDRnB csvby9kluYzV3fXGqjAYTNCdR0Xyb3H0c2kvEzH+Hoolw7Mb6t5Lp+nv7mwoDMb4iN1JvYJv JTdB3SLphcelPb2HwQib9YpMTa3hQRPjEKeq8O5N4Vg5ubjGlbHJogdZI+Nj9Kp712/Kxxnx 8OW7BCkYh3CPMpRH53pCdJHSSwDyhZ1cXOPKOeTGysr0mxi3ANewpy1dfQMQhH1455aZDqZ2 pCw9VFqxswsmrvwlWe5h3PMg61Avz6ByasM9mWH3DnFLaeZIbY77x0YaHoX6K4WoVLiPxqhL D8ZgXCYr6BWZpqDC93EoDfcwfu7SMk7OrkHZrViFZ56guSE/TqZ1v6i0vOLGuoJgjLcLxi+x tAyvZBz8FvpGh+sfhfj5y7SMwQQlPsMp1NRHbahNk2nZKyoiqZhGLYgN9PbA+EWlldXxoPHR YdyjkFsydcmOjqt7agWvR+EJKGjOz4+T2YUROQUNsg8zAbU+L01xuN1c3MIftgHWO+TbHwYj lIL4AC+ljYXBYDBuARERJZ2gfwyCaG0VadGSUU56Vk7ogfrYQ3V3g32Fk+QVGJlR0gn1zyAx yDgEYStSb92QGeekZ/jnLyqKozFOLu5BD9vwrEEIgoa76BRZA2GFMJS6NDpMqbgTECrtkqhm xbKcNlJxtFyNboEekSVt3QPCgexjk+ruYsT9uxWVWc+CxscgbHlKlDBmJ1ePoIdtBNETFcV2 nVw9gnKw1cUZubE+wpqxrwcHQVNdbuzk+wWD8UsqqyD2QFDvyGBddpCPvyioqMgS1uvBMYha XpZ6Q9qjMoLIP1kwCrEr8u6I3YadXDFBOWUF1wPexVBXTB+FVp12XXbD+tz0Sm/p6pNUNjw6 RK6I8w+ZZOl4BUVllbIg2SwxY8MD2OzAKD9xERd3THxlS/mjstQbGIyPu1d6JegT7bDezoHa u4HebtL6nFwxQTnlRLZoAgWjELs8Ny7EW7lltyDPqFJcz6DyVuC0PCuKxmCc3TBBORVEzns5 T08bSllSSqhCiMFh8SUtkj8C2c2EwluS+Rea4gpGBtnlsbEhwpXn4+GdUdXdLxqcIf5Ae16s r4fMrdEFg4nPa6V/1HcRZpVPQ9yHgZl1JOL+JC9PwMC8BaG4r5wPRwGJuC/3ggcMDMwfAQ61 qTXu+BENR4/4shmmS4KBeRf+eOI+DMysIxT3bQpmOw6YPx5Ccd+5AeK8TQgWivsyGX1gYGD+ MHQ9D/K3tTxpmUUWvfMBA/NfAizuw8AAPpfFItbhs68cM3B1CcnBYvF4ApXB588gtTjMnxQe j8ug4HHxJmp2ju6BxVgcnkCgsTmTHPbmsDtpzWVPgo8svxKSfLcCiyOSZN13YWBgPjFEjsF4 rIja0twQTcRhy+i4J8TZjg3mTwEs7sPATB+R6fHL2HA/p6Om91ksFovV9XpgGNZuYN6GyFO0 Kj4k4JyGVTGrmcLigL6+SWy7BRMTAz08Tq6rscc1O78KFovF4r4eGpL3MoWBgflkEO1uHktK jucpM9PLFkmk2Y4NBuYDA4v7MDCAWpOTeXXdojlf/f0fX3759TcIxMpl68wiSHT4bCbM22jB v7xutGj+ws/+9sUXX371LWLu4jUb7QoVkuEAAAB4XnzPUv3bb//9t79+/vW//vUtYuE2Lc2g asZM3GlhYGA+Io0t1X76P85dghAxd/Ha1aZJOVXEKZLjwcB8YGBxHwZm+kwIxgi3z+rv+vHr r7782+f/UlGZo6JyDH1fzgUXBmYyxiCoONpc/fd/ff3VZ3///FuV71VU1pwNCilmKpXkDw8m O+xct/LLz7784ouvvlOZ8+PPm9A5hS2TuzHDwMDMNiMQVBB+QXWXipRfT7j7ZLWBgRmkSYKB +UMAi/swMIBDI+DKs1KTkxJFpKdllr1ic2fo0wrzJ4TJ6qgvSU1OEy+d+6kZWZXt5EkMWKnt rRWFiYmSRZaSXSjjoAsDA/OpwWDS6p7cT0qV7O60rAdVJCrzndxpYGBmDizuw8BMn4kJQS+p urokN1vK81c0rpKlAgyMAgIIYpPqy0tklk7BCxx+EgPW4fExWtPTwiJJuYc5xa+YYgddGBiY Tw0BBLGItWVPZXZ3YTWh/a25t2Bg/oDA4j4MDAwMDAwMDAzMpwUs7sPAwMDAwMDAwMDAvBVY 3IeBgYGBgYGBgYH5tIDFfRgYGBgYGBgYGBiYtwKL+zAwMDAwMDAwMDCfFrC4DwMDAwMDAwMD AwPzVmBxHwYGBgYGBgYGBubTAhb3YWBgYGBgYGBgYGDeCizuw8DAwMDAwMDAwHxawOI+DAwM DAwMDAwMDMxbgcV9GBgYGBgYGBgYmE8LWNyHgYGBgYGBgYGBgXkrsLgPAwMDAwMDAwMD82kB i/swMDAwMDAwMDAwMG8FFvdnFR6b3UEl4kk0Fp/Ln+1gYGBgYGCmC4fNpJLxRDITvnt/BPgA dNLbiWQKg8GZ7VjeGz6ns5PWjiPSmRzep7p2OGwmlUwgkpld8PKeRWBx/4/BxPjEaC/g8rt7 B4fGZzsYGBgYGJjpMj4hGOjhckDP4ODobMfyp2BkqK8b8Lq6h6BxwWzH8n5MTAhG+7u6urpf 9w+PzXYwUzAuEAy85nJAzxC8vP8kwOL+rILLzQ26tGv5Ebuc9nrabAcDAwMDAzNdKgrjr+iu 3KJ7u6OGONux/PdDA+Ae5vBm3YuhIU9nO5b3hlyRkmS5b+5Wx9sVLe2zHcwUlOXeNtNd+7tu HLueNNux/ImBxf0/BgOdgldehjtUjX2yCxizHQwMDAwMzHThDvYm2W9bbXAtM6VptmP5U1Cd F2ZssPuEaQ7E/YP/gTM22IOLOHHiuMWViBLybAczBezergT0xhUGmJz0ltmOBeaj8CmJ+9js +35XdJAyHL9yJeDhKwC4M6iFC8CrbH8Li2NIJBKJRGkhbVMe103687mdRrzvra15EolEIpHq +leuxL+iMmfS1PvTlpXprrPim60mGcQa6kdtGWZ26Ghsfxx4WfOoGtLcJS6/crbDmWUIVbhE tKaaqnC3n0MH320EbN5sRzX7tJYkeDpqI9VOnrXPYLwiz3Y4MJNTkhNpqIpYpBpKr8TPdizv z7OIYNuzsl+/yPMenknV/4GWWp7Eul3TRmqcOufwgN083S8+KgC3r276RfWkt1fBfyCoDwvx cWH0tTNIjUNIh+gXLS1K19tLEmKN1v510ZUbpY2EjxRTaXoQ2lg8t6e9HjysfvPQP8kKPas6 Z7lqOBt+djWL/CHF/R4CrTTkEgqlhRKjqYe6lFBC5ffMrCIuofxuyDlxJRahN3PxU5Ssy73p YCEueC6ktJwww6bek/4OQa29xtJN2g7JD2gftWWY2WFiHKLnJHiYn0Gdv2Ad9wyC+mY7otlE MAbV3gqyNUShUCiUlrqm2Y1yJql3tqOafbo5xKK4iyhdTdTViJIi4myHAzM57IGeaONFCHWT xLj62Y7l/aFXNibYoGQ5bXrSv7yza/BDtwRYuPyYiygdDZRlVPkT0vQ/WJ7pq63+695TqRDr E79vDnT2N9121Nc+gbJyv/O0Uen62EB3s//evXv09AMKCB8pJhqpId4VhTqGQqFQqFM2ISHF zDeW7+zhRZ7/6Rt187S7Lz9SiDCzyyci7vMAwJdHXLI+e/KwNlqKU2hoUhkOgJnIfTwAcM8S Q0Kc0OhLp41V1/xD9fr9J62TlaQxqEUJLo4uaLTxiT1HDh3Y6lxBpH/cF/5pDfX5Cf7OoWn1 DCLro7YMMzt04mk1CdcdtXbOVzV0vJM72+HMMpQmUkG44zVbNNro2K6dqqoX3Z6Dzo8k7rMB qMq5l/e4tHEWxPOXDwuKHqc/n6rl9rq8+BuXNXX3rzlyk1aO+6ihwUybtldl96NdfaJL2PiO 2Y7lvWABUPnAStvo5KmjF2S+f/3i4wub36W+hgd5hU+yqihTXCbWPIoLMVE/hdygGs6qmq62 zQKgIjPEOzq+6N2C+qhQa6qyfW0MVJf8f6rOBdXKT0iYbVXPk4NsfTJL2yiTrx1uB8A+jE8t rZj8aMI7UPc0OTwAjb5ick5vyzdrzkdFFr556FsbShKj3f2in/GIjPdtm/yy6lny7exWPpX9 vlX92fgDivuvGTV371kd3qaBuWKNEeHqiwkpfsXumWFnuhnNjzMDMRgMBnNq8zp1y/NhL6Yo SajOjg3DYOyuXDTa/u/fzJKTa3jv3ZGZMNIzwShOColKfdzc1v1RW4aZHSYEELeqONHeCKm+ Z5PNfQgCsx3RbCIYh/C5GbcDMBhL8/MndqistMjAN/A/WvN0fGN1fkYdC4I+dtoJHr6zPj+y lNXVP2nLfd3M+oJAe6vDv5x0Tr1d95GDg5kmfaNDdTnBvkk5jQ2dsx3L+0LDPggM0D6y8wLG +pr4+9f7hkdqM793eMaVcbEd9QXRz1ivByZNOdPXRa/J87e5ilxw0jXrTsP066W2lacm3YhL a4H6Zh7UR2W4a4icE+d/9vAydUPbhMdK1wWjQ+yKuLi4jMwK4pQ3PNBcX12VXfqhTvZzOolF dzEYNwzmssbGgzqmhrFvfqzQO9xfkx3onZTb8or1vm2PDQ/icuIrmtrb4We3nzCfiLjPBqAw SHu/0QW3gIoPV2vL49YQre80Q6cQ96W0ZXlft9SaBXEf5s9IBwB3bHfrW8PivpTadLfLltof U9ynAxBno+PoG/yo4eM0KEsW2tXD1/j2yzcUIZUnZ9ru0oigw+I+zH8WHhlQQy5tP3rJNi7j gyy2jKuO7gHmca/eUKS99G6a3f6jkdMX9/9wNDQ+Dzj6P0d8JhP33w4TB0qtNc4HR6bUfNiw mNjqUuul+y1j3ibuf0jqs+6EnkVaPuE2/bEfg80Cf0Bxn/D8Hubytn3GJRD1A/78y7c6f9V9 anFfRH9Hc/21JQevpX9scR/mT0pV7g1XQ1jcl8KhNty/tmLltQcfU9yvzEkINdOJaoCgD344 +S1gH9bdMlvt3EDkTNmyYGSw9fphx7BsWNyH+Y8zUJzsZaG9+0okCep+/yddrZlVUVfWu72i 8oemKjI22NMSsN8+PG8m4v4fi2EIeuCrZWo7mbg/LUiJUaFBhs5PPmxYEASREs0w12zeJu5/ SIZ6wIPze7zvFRbC6Qc/YWZb3Oex2QwKAfsSh71hsUvnomlgAlYMgUJlsOWz5HA5LBoZi8WJ i+DbydROwO+aovIPKO7zODwGCY+XtownUBk8Pk/5Kp5EojK5AHRJOthBIYhibqd0dLIBAF18 0EklE/FYLBaLxeEmN9Rld9LJ7cKrbD6TRiYTRcWxBBqDzVWSQDkcFo0kGRwihUxn8Fi0djwO hyWQqIzOGSYc6uLzOql4UYxYLBaLw2IJFAZbMWsKp5NFaxeWaKezOrk8LquDRpDvLwAAAC6T Sm3HY8U94vKFHZyiR+wOuqjDorplqxKPeieDhMXhxFf5XHF/sVgihdwx/SOCHE4njYTF4bAE Cp1KJrfjsTg8nkRj81kMUcx4UcxyH2PTSfIx0juUR1k2KiwWiyPiSXg2P85GSdznsRgdZLxM dVh8O4XKmnR5s5nCoZMMDoVM66ARqCz+lJthangsVgeZIN+wXFV8Lo9FbcfhcNh2SgeDweqg EiR7EE8k0Tq4oEtYlsPspLVjcXgsgcZgMzsUglSaQRmmEve7AOAwqe3teCwWi8XhCQQam83l AwB4bMnsY/EkGm0GzwQ47E4aCVuHwwabalxxdL9bLNN1IqVDaeHweFwGBY+TzA0OTyAz+co7 8O3w2FwGCYfDYeNM0HaOZwPlWm6ndLAk9w0Zcf9pPUk0PcKBVXbgVJ5BQjuByuJ3zXgx8Fgd HWQ8FofHkpnszo4OSrt0RRIoNKbC7heOJBYnXPwsLp/D6qQShJNCpHQw5EaSx5FbOVgckURi cLsmC5LDpNFklg6eRCPTGEwqic7pknSez+N2UnCKNygmh61s/snn8DqpRJzMHmynMelEEr2T qVBauIBlVkM7mcagECmylrldfMChU9oJotv35Ia6XFYHhYwXXu3q7KCIBxKHxZLpbK7SbYLD ZlJJMu1S6AxxzAQSjTnzJ15dAHCYlHaZ+cMSKEzl/jKp7dhXz7GZpqq7L1p4Jz2WlCbRGawZ fmfw2NwOEg6HxcZcuGLrfC5YWhkWS2ynMGSXt0Tcf9bQTpIu78kMZuWXN/GNhrqiBSxdORQS hU4nkemcLt7Mb43SHsnsfQKdw1Gui8fqpMvsQTyJTK9qmEzcZ9Hf3t9OOpnwqgKbaXxY190v Kl92Y5Pone/5+PMt4n4XD3DoFKJ4eb/RULeLx+XQiUQCTjI4RDqT2k6id0iDFPa3KC7E88Tu i2ktJQ2SoSRgyUzOJFXzOJ10KgGLxWIJVGYn589u5vuHEfcnxqHRXsDlsFl59/1tTq68GMZi tbFYLBaLxeZxQf8oBE1ISwsgaLCHx+WypHT1jb7JkO4DivvDPa+75Fp+PTA8MslVDovbOzgm NvwTWeZy2CwWi8Xl8noGIUgAQdDIwMBrnrgqbtckhrpjY6N9gMVis7igd6h/YKCvS1ycA0Dv kFKnBRMTMoPD5rLA4OhwXy/gcVhsDq+7dxQan1D8zJsZGXgtjZHFYrE4vO4+xbOYgrGJQcDj sFksFrfrde/wxMTEaD/g8tgsFovL5feK+gtBgpHBwdccYX9B79DQ+NjYiLCDLBYHdPfJ92hs eETaYcWqREM7MTHcw+viiK9OTAjG+nsBjyPp/tg0XReFQ8fhsDi8rq7Xfa+54iAHhhRilvvY 2HB/H182xq5JTrlOTECSqETFXvcOlT1UEvcF46MjvVwuhyXLFMtbZuiEg8MFg4OA83pg8B3c GQXjEyOSJSptWFqVtAtcLr9ncGKkTzS/Qnivh8ZGRXMsXgwc0N3XP6QQpNIMyvAGcX98ZLC3 WzwsHNDXNzQOiWefzxEtTF7v6Nh017dkunMSQj3OafgVs1gUcWfYXH73oIJd5wQEDfV382W3 Au/14MA7aKATE9BQTzefwyqPLww4t9yquLJZ2jKL3d0/Ni6ZP4m4H/m8v1eyzJR3CgRBgrGJ kV7AZcvPYP/gyIwXg2BsdKSXy2WzWLyenr7+0YFu6S2Pzed1D8jfkEWOshzx4p+YmBjr7wI8 9mQjKZiYGOnvkl05LO7roaHRSVbE+OjIAGBJViSbw+P1jvR3d/UNDg3L7MGR/u5u+RsUX/kG BYkWcE+X3B7s6e7q6e3pVig9PioYkNkKbC4LDPQDTk+fvGXu2OBAT5ekNt4khrrjYyMDPVwW m8Xi9wz29Q8MSFYwiw96BpVuEzIjyWKxODx29+DYcF9PF4/DYnP53X2jkGCGd28IGhsZ6OmW uZ+w+d1T9rc6IsDa/PDxwMcsFlU0RKBrpmf2JwTQ0OtuPof1LOaR//nVNo9r26iSqWGzu/vH xiWzJxH3b1f2yS1vZYNZwZhgpKeLI1renDca6grGRkZ6ZCeQx+sd6OHxeweGh9/Bsl7SI9lF Bvr6lesSjAmGpUGy2Fw2v2toPMtbSdwfG5Lr7ySGupKqXoT7e7hoW6XJNM7m8l+/02KQ4y3i vvzy5r/RUHdssEemLIsDegB43dstDXJ0qK+Xz6ISsHGntzmEJSe/lOkNv6d3kqoFE4Lh/i4O l81i81+/HvxU/Yb/G5ltcR+Xl3f97AbE93MQX3/+v3//7POv/oUQs0rf7Eae/Nm/F8/S7Y4h ED+Ki6zYo2OSCqidU1T+AcV97LO2G8dWLJK2vGS1aRieilO+uvTIEYs7LyQ+Abjc3CC99QjE HAQCgUDqeSQWAQCYJJBifHzXrwgEAoFYsHD5EetJDHUL7rqePoBYsHD5EXQuOdL++OktCAQC gZizELEBHVpYr5Tkuao0zfYYAjFPGODWs6ccIwjZVsjF839GrD5yJTz+TccoJ4HZ3pJyafnO XyXzMQeB2GBwo6hAoeGqhDTbA8ISSIfs+9W4mpwAy/WI+T8gEAjkWa/7ReKCL2NMTQ8tQSAW /LIChc4lN9DzE5x19yMQiDm/IDbY3ChqkKs438NZdzNCilxVQlpLUkK1EAvmIRAIpL5PchG1 BpdleWDR/J8RCMQ2/dN+CsXfQGVJio0WYu48xAYDBxOdU8hViAW/rFSzyaM8CDExRi5BiP/5 ki73sXx3zVOyMR5y9ElWOmVJrcZmXhVFhUAgFmxZqeaWR4m4rCTuY3Ou+59eKVMdYtV+PbM0 MNlDivw7jjr7ZRo2MNBF+1uuM0ubySMNScMPH/qfXo9A/CDT8HqLdGlV1OrW9Cv7f/lpPuKQ gW9o+EP/K+sRP4lKL9uqgQ6sFivyz+8kWe9DzF2E2Ggb/iQywFFnn2yQvinFUwYxlbjPBqDy 9qX9B5cgEAjE3EWrNtoVPnlFBwC0PE4K1kTMn4tAIBDL1KzR9xqn3eHnj5OsNRHdg3U2AAAg AElEQVTfzUV8/fnfP//iy399KzPm2w39AxSjbMG/vG60aP4ycZmff914Mor64h2OvbYUv7yu ufCnOYh/fvbFF1/84yu5lg8aBGYAILkBScR9f1O1ExsRCAQCMXcxYqNdRIlSku627Cwf3d8Q CBVJZasPbrqaQWfO+D2ktmw/H92ViAUrECdvFaR4+50/IF2Ra4xsooub5IpXFCVc1RDe3A47 B6bVUiozUy1++3meCgKB2HEu8PoTuborM70tfkPMFUe5cPsxres1inKzsN7btlf3Sodmubrt GcvQGFMtl6dMyclfOq4hyXDBVsmsIOYhEBuNIksfK+cHp1Q2Jpvvnj93vrjhlXutbjts03RK iFEoXXE7QbbhHUZI3asRF7boxclY5rLawXN3o91rFgs39Mot2pMY6jY88DXSWYFYsHKLdgwz 1dvIaL+oOAKh7VpUU6fU48L4KxqSPfj7+fOuYY3J5jt/nDsfsUbDLjapSfEDb4MFwPMoo937 Fkt7s+b8rdgn8oGWR8df2Yv4/jvEvz//2/9+9vlXMntB1S04QynMN9NUUOOv/uPcHxD//Ozz L7787GvZ5f374QshmTIZ9iTifpDJYa0NwglcitjkEF3erDiWrZlpHtqS5f37Gw11WzO9PLRX SFeO5kVNIwcn9ZNOJeyWd8gt05hf7af241zprXHesg2bHJ5WKNfVmpnirr1OpmFtR5+s5wEo JXE/xxEp7u8yxKbJDHVbM1Lctdd9/x3i35/97R9ffvXPb2SGca2WQ3zy+2Uleou434kHFa76 O1YtQiAQCMQva3/XmdpQtxNfX+Gybceqn0SDs3ztZsc7FgfVnHzjU8RB5jgc0FyP+OafX3/5 9//97N/ff/u9uCu/rEWculMySdWt5clul9chVBCItZdiE0o+Vb/hj8UfRtwfZEFN3kY71yxV +eZfX33x9//57GsVFYSKioqKisqS/TsMY5sgaEBauhuCMl2RmzeqSNEKfvWm19Y/oLj/xAV9 TK5lq7ulDcpXf16jst07E8/qEv6/yDJ39RIVFRWVTZuRrpkQ1A1BUMOd+Kv7VFRUVFR+UFHZ qDuJoS6Z8irYQOWHJSobT/vlRNyLD9YSt7z6tJF/gVIi7i6BIN3lwMYNwjLLtswxzGh6fN3H YN8qlaVrd533aYJYMzyfXB9nJYpR3PDBC4F3FBruIgnSDfZtWKKiorLppJ1byYBg7GWMwfZ9 S1RUVDZtOeyWJewvBPHrM9OubBD297RfTgGDRGoI0ldRWaKiorL6zIVA+R6RnjQEaco0LVeV EMH42BPnfZobVFRUNm094pE1IegmxHjr712loqKybOs8o6wW2jRTHXWNj6U57V2/QWX1wZO6 toEW21V+mK+y8Yz/o6SHGSkWopjP+D8qlM9R3P44NlA2xs3aRzxKFOsWjEOE26KoVFRUfpir stHK/1FUtJK4P8BoqffYvnXlfEl9c+b9dOxGawVVOeB2Ym2AvorKYnHD27YZpKafW29xJ2Wy 0m+hv2O03kNvy4olMg2rHL8prUowDuFve+rtXamyeRvKIWO0Pkhvy15R6Z/n/bTX+iGpSdgN PnEo5ezu3xarrNYzDo4sqA04KxskyvMBBE1havEGcZ9em+Zmtl5Uy/9j7z3j2rrSdu+Z857z /uZ5piRPJoEQx7GTuCVx793GuIPpvfciUYVoovcOQvQOAiE6CNF77713RBPVyw1cwet8UEHN NjjJzCQn9ze8117l3ktb1n+tdV3H1QKwpfMQwo3XL8rtBMVPCwgICHx36paQb9/E8ju3CbPH 6usXabbXTp4W+PyzT//x1//65HOWZ/jjZTHdXDjP1ssNCMuijcVvsBS7Y5Wewi2k/cF48xKW 2RqKnRL44rPPP/nr//7bF3z8Wy3v+U4vdGSeab3BhPs2nlE+4oxSx9URQWXjHNWuzbxodVU+ /9MBZmVf7xGQDcts3LGPx9pMd6vrpbM/7RG4Y+0YHNNNMLwkILCH/kq5fxuZ3A8hS5ZXXqwR MVdOnBIQELigJOFZs/FqfSRKSVnwgICAwE9XJAxIkLp1DGvt1XpLlNLZ64xe7trz3TnLgtJ+ Hh/S5aEGoqrAif30kt+duXPDvS1GTzo0vbScRQCnNRJhKMj6gjp+HxlM4NZw33gFhyOdFa8f YTQscM4KYySH8XQy4ii9PLRGVL10bB+9vp+u7tUgRmgcswtmt8ydJhEdZBhTUuAuD0Pd5enO ZOdLAj/uEbhnmxsSQ0w2ZBa/p+KcVss1Ypo370lakcPXD+hljtf4OypcOyLww9l7xgH98OGO hWimm4kOyFNb2flB2Mg4hWO8g09TVC4e3SfA9z+f/P1vf/mvT75glr6kKu3D1c33x6t1WGKl K3xS4Iv/+fyTv/6fv7NO78PfH0JGTi7OMsoy4b6tR6iHKKPUCU3jsErO7/NnU08bneRP/UCb Doffa6j7bKqt0eniyUPf0Or7/pygoAvR/rawZ3xF1Udoy7x6BostdYVPsk6yE5oh4dx1PZt6 0uAoe/LQfkbDB+57l8wnYrjg/khBMMt4tXgY6j6dpFfF9+kn//jHf/3tnyyN/3hOBBU4AB+/ gj8nPgD3Kdl4jBRz4tx/r6EuJcsWI3V4KznaDupa1p46KCyjk8P5Qe6iAgJffvk///3///3T zz7jZxnNfQdPHlU/XX9UFyZz/Mp+gR9FzczT/lP9hn+P8e+G+9SxsY6KHEJ8CsFM5sRNMUlD OwIjsipqu1i0XodIRB8TTUVtQy9CPJ5WIhTnhdIRl9XAVvP4sQ1+Mbg/UZuS7KgpJmnkGBMf Q2s5GhftoCMuquGU0lA3AQB1ktqclYm+LihnpO5ELKrrmwaAjqyoo6MdZEKYrfyBS1p2IQmt A+MAgJVFMFhdSs4kEEJ8bHSlfrponMNtqDvW31KOd7HXOXfwmvitm+rmVh6hBAIhPirc9M6R uwjv0EIWmjmYS/Ay1lTSMfIiJOAJBAIhxM3CTP3mTZErB795oG8XQqzr3hHamO2rrQjSkUI4 +wbHMJ5HPIGAMZSXQVjHJjSwFKX0DzUUJEaHesruVzJFy2rqqcopq9sS4hIJBFttC5cAe/IQ vc7emprCdJyzHfLqUTMXC2lFWTk9a0wgITEm0lP9JjqqLLcHAACWZye64gyNVLX1rD0CmZPB 38pCR0vDPCCxByww+ND85GBnSWIa0VPvupKekqyhjeqD2+qo2PgIAsHDEm2Dtmct/N6gTA42 5IXjzK7wnzsuKGro5B7tH2Erf/P6vYtiBiinAALOLRT54LBxemEbTSR9dna8PM5QUkUbbe0Z ytJHDR0tM3Rgfg+TYXXlFfmait6h94pAIBBCfSNMJW6InNz7TyElVrhfFx3oaqNi6k7YihCs h5mOhIIGrq5pcJ5RjgpAUbSFjqm+DSZwq2FzucvHzwvuVkuemNk53KeOjLSXZxMIKYz6orAe djqSIhq49OahSQDA0vT8UFV+mrfBVUWFBzfUMCoadszPoJ+vs678bUX1oLrmoXlA6RuoTwwL 0b98RF5VQtgAbWO71UlLc21ZBUMn3zLA6xDJu+D+KgCU3uoYT9Urt0+fu2mVlVo7PjG7DACY nxhoTA80u/zfR+9qILAFDTuY35SJgfoSQmwKwVjyqqyatn0gS9JJle1suGm8qjLBTlNcRsc5 PjSWnp6YCDvEAxFN14ysxh3K9c+Pz3aUpKWmEDASCspq9wyxrC0XVHYMM98bAEzUpRL1f9h7 8vYlOQtbrzACgUCIiyJYK8noevpkN7Kop9Tm+jph1MzsCAQ88wkGutvqSAlrBGe0DL1L+Jxn UEfa20iBWDvJvaIaWlcVbNDOHswOOiMQKspKVrjkXsDYTUsZ768rTohI8ZC6rIBSlVO3VJG/ r2kfn4gnEGzQKFdrl8Je+ohqc4PNTOTVNO0JiUmM+e3taKIsch+TVd/D7OM8AIURZlpq8gb6 dlvJ8bUxULl+8vwxQeOiOdoC20xXeQlWV1TfNYDxVAiEOALBGiEjhbRPTm5mGdJYZXmkk/Z9 LYuExEhGwzgD4dMH/nFANTikkGVJsSYCZ2Wqom/nTSDQ+hjsYqZ7/+ipn/bfC2axzF1ZBJSW KnJWOoGAtUPo3twvEsptqDs70laV429uJbrv1F3Vc1JmFi5YAoGQEBHsIXlaSMXBI6dp646B zARXpJaqgak3ISmZQCAQgp1NTdSEbty/un+XqJFrRHpj38DOwPTIWG+8s+hVdaSvK8sUczaQ VjZ0cCWwZGeqt68un5AQTvCQvHBSTEbfcat4YUvn8My7m+AVc2Mz7cXElBSCtaiskoaIMev0 zius7hxm37mfpPvD1yfuXFawtPcJJxAIhNgIgpWClK5XAKmZLZ3zw0OtZdkEAoFAsBY9IG/8 TkPd/gwXG5SRhrkns1Ufaw25Sz8e/+G2SclCz04FYcbKS6Ld9eTNXPFJcYwKY8ODrRSuSKIj UipYXHKrwwKN9RQ00Q4EQjKjYXvtO6cvn+L/8307drg/2lRQkkMgRLr7o2W+PmAWyW2oOz88 2FKWHR9GcJc4f1sbYeHHksaskqb+rW+Dj4oPwP2VBUBpqcjLSicQAjG6Ord/FA7nbag73V6c 56dzWc4iICSa1rmYcKyl/PHTuw6Im0cwNxPQxhuIMdG9cVLMNQnHTGVaFqGsj9dqdG9lgoXK 7j/9+U9/+lohNKr0dyvbtM34zcD9jRfw0WBrRXEhyc8JoST0nRiKREomkUgkEqmwuqJ18hGE 9I1bDLtdQ+fYsCRaiXQSKcBWQxHhlJTctMy7/l8C7r9YpYzj9Q1UDdHeYTEkRoRiLPQQJp6E AhquWOzvjjdD6ypeQMSSKgZnn76go5g3z98+GmitiHGQVVSXR3nX9M9C+ApCCCanuqpIpPTc XH/d85eQHtyGus/WHo205Oa6it2QErl6S0NfwzaU1rKvsZKKqrZOHIuH4+ORqUqsvqgoMzlp +JgAoweKKjfOnhKRkHeMrWwbfAS5Dge8M96+3Zwhu7m7OFp4bY2YRMIFOCN0FMw9quEi08/w 1bO3sy1VpQUx1jJoAykZjL++6HU1i2hsLIkU7h1jZySeND7x8CWE8CWYnekszc3JcRC9bmWi rmdpLK2kaRxISk4nRTsi3bwCcYwBLTXgEx0RSpq2gSRSOq1lfGiMk6GoGBJXMzP2ZKuTi31V 9aXRvuZotfMyHgn68hJqSHdsMImUFBNtLikeWTMxti2D5FdvN2f6qkpDdIUlzxw5L2rimJub GmKCVJG+JqwpZ+JNys0h2csporHOOTQa8hbCmQa8mwPCQMsujJkdfIink6G6hGFy7RygN/tk 7nWFm5GMNq1XJBKJlJtD8kQi1G8cPXz1HCvcn2vrT3cVVHWMwacy6kvLyfa3UVNAuKSktrBO 76G2/EBHZW3jQBIhg95wlI2C8Mldf7/vG78Te0p6vFnfBAPN5UUFjIZzc7JDrFV1ES4+aa1z EMK3b+HTiYHmNKypucIpEQN3QTXH2KA4WllCdpY9UlJW2z4lrXUFvny6MdNYWeKso6gjKSSL NtM2Ye2ko66YhJRtJqV3kbsT74H76w9nGorDjaR2/5/LWjg/0vDIwnMI4dvNjcXeyhgjwQc3 rwiaE6qGHj/b7tbcl5sbM72VJaUkb3tTHeGriEASKYMx9qKKurY5uLWd9PnS66F4Zx0lpKWf Tyw9PSRSiAdKB4ny8+NakftAbG7Axd6OulJSqF0AUnivfGAEfqtlcn7b2NPnzLVMGtxXELl2 TAShY8+YZlhbRwtbbf/iCdprBEIIZ6e7U91vqDvGJcUz6srJzgq2UtFGuPqlt+6oi2/WHz3s KymL1JHQ1bx/V9tV0cyJREqjVRrlG4pSE5I2wTUsMEyPX268me6tKCmNtjRGIS/J2sTqi4mq Wnrh4kmk0MhIB1mZlMbZx09pnexPcBUT0rKMD2b0MjsrwwMhrmqFi2FbrRhszvW3klGRNMUm ptCTkxwTYqtw5er3P6r7k2nv283XL6ZznRwdnW1841heUFhfB31dVYxvHVxl5vH5wov+eEcZ PUuv4FBGwyQPA9Wbh44Ia6lEs3itzzT1JjmKS5q64YkEEolEIqUmRPgY3Lu276+3zNktc9fn pvsaSkmkrHSi3b2vlB24DXVfrgFKb1FapPYJSTHR89IoJTNfehbRqtoqOsoBJZPMJ/hoYKTY 30BC0tANH0kgkUik1PhwH0MROeUbp48/kFFzS6zpHH4Md7Lx/A2ELTk+SJQWCuW7lZ0oX3sz PTU2j9wXT15TmsuL80lRaEMF6fOChlgSKZNWury5Yegd36rvis03cKGnrbaEFGLjgxTdp4iN Sc5kTu/8wo7xtRfMx0KD+zL3rx9/gNRzDKeXCrSxQ9vpY8smWW0wXq+9XulvLC0sIJFCbNQM pN9pqAv6S/Kwxrc0nfEp9O+NpKhAG7kTJ/gOqfgV7vTDCtepa71xdupo58Ao1kkWaKOjZ2Jr R2BZ3Jtu6IrFSNzWtManJDAaTrNVeCB9bp/AbUV2uP+UOjpYRyJlp5OCNUTuGhlzG+q+fvZ6 pa+hpLAg0hyho3lT3pWl8cKy2q6Rx/DVNs+kvSM+APfXZqd66ktIpExiEuY2n5Izb0PdjRfP KNm2puZWFu5bX4IBVopSZw9fvq7p1g3BSwghfDI/MlBHyiQSMLePqKKcneJZRlPTNzj7mKvi x2ug3OeGwMG//emzixpa8X/4if/r4t8N9+kxDwDe9rYmyiqGzOMqzW4Xba9vYOCSUjAMGNoQ M6OdpGRndSkJU1xWSxc3iPhF4P5EXQ7WzlDFAIkraJ1bpLveUkdnmpODDKSUDYNxpK4JAMAS BTTZGxr7e8XVT4Dp+elygqsjNqGsomsGgJHJoWTDszqh5PoOrpabsgNQpy+icrnhPgAA9JWl +d79cvf52zp+2WVdMwCApbnxJryCpLSFY0gpkyx2J2HczRAGrkRmcqY7SnID9WVuH/7yINKf 3Dr0/vFzxExnEyncQt/QPbWtZ5zp87sEQFNeOMYW7eUaWT/CQiEBAItTg3V2ZyTuid6QR5gF RCc3A+oyAF15JcUlqXVsW/P6SogBwrtuCMtJGdh6EsvrJsAKdXqIHJhR0dMwAgB1dKox2U5W UssSF13etXXneHVJhC1aG6nkXNw2t8TiPbwIQG2IsoT0DSERHTMH1+SKuYUZAIZqi8uzUwuH wfbP9M+O9CbIfSclj3ZKa+yhtg+V2dz69PBt04iExhEwXNWboPOdZCipZggAQB1tbEg2lZVU swouqGCZduPVSeEYfW1DG5fikbmlVQAmOpP8A3V1FN0IpXML9HKU3snCAAeda4cFbinQ4f4i AE1kD4ydQ7A/64INmB5pL0x2sdLScEttZAKgWQDirQQlEWYRxImthovwWGfnADdCM6duykcF daSyMkr1xG5VL3ITQxV+AYBanIKo1A0heUf/lBbmZ3CotyERa6IlLuqaXNs7CgAAPcPdPrLf HhW+Z+QUW1HPnKPjVUV4jLmxkQqqpHN+mcs9+v2a++PtCZbOqlJXUCVtzHupI2NVcfonjqj6 EDO6d0ghAdie5v54R4ZvAFJN3jg0tXNhgt7w/PxUQ56/jraSkXNYwTs9cd8f29PcTzE4vOuS ogG2qIoGJhdnQEO8hZK6ZUByIaPdrjw3P4yTU2BRC8u26Pnh1qYkZ4ymhnN6SyUvMPe+mKjr TjU4dvSimLhLaGbz1pbxzpwMXxNdQwut0Fa2abYwBmqsZUXu3LypqGuO9SS2LCytANBZXVCc k9FAe1F0kixdTLX0LOKJLYCpwzHVXUcKNJEQFfdOaWwZAwCA5bnhIbKukY6JoUt6BktmB6vT I83kJS4JmtLg/nR7bWawBcLEI6O7f5IJBxcAaMgJtrJB+3nFNY4yX1B9aSkuyAun0YTZhQlG w2NFoRhrS5fEympW4puNMtBCClulM19ulLaC/CgnW2evyHdY5naRI/zl9ouGccN9AACYqCEk 6/wgcPCusENKVssYAGB5bnSIZKF6S8s6JJtpLtMZj3IyMTT2ziweATS5F0prfrqPluTN41/s Nw6t6OJV9/tiqic/FystJmrumdLdwvL0O3JwTsZqBpae6W2ATQ2FOgKqLaXuomxDi943I7cf 29Pcx+sf4b+gjAwuqaEdx1iggPpYM3lVK1xq8TuWpLLMzhlavxPutwZKKeuaaeK2fHsGKtNS /G0d3SOz+pandrbuOd5GxAVh7FCRJb3Lq8xbqVMj9bHWaENz/6SSpikAwDIAQ5VOCCtDa2t8 aStz9WKgsjrWUvvBpc//131bnpr741VtyahDB1HR3HCfFv8BmvsdOThfhR9FInjD/fHKhHjj y5+rpld00p8WdWq4PsbKw941LKuWw015J5r7lIFGUrKbhaWFhSu+uq7vZ5v5/sbjNwP3t6Kl JNJV/QSKACEvze3Hc63pqZYqYtpBhLbFOfrgXkM430J0xCBQtn45vPfc/3y4vz4310y0lRAz cEvJ65vb2mW63FwRgbEysjMJa6XSSMRsdk6srwq6kArhazjWRk5MiExPb12B8C2EjXh7D0+H pEauljc324Il7mB8uOE+hBC+3dwsRAmKCF24beJPZBDe2eZQPwxCVCuFyiAgD3uKizxUxXVw Ke1Lc+sQQvjq8cJcKdZB+9KpswpqDrlD7x8/R7x6sjlfHmxv4RVJrmDz+Z0dbUmOsLfSsavs pD5dZ7+JkmXrpXH9jDBC18ExsoY6/hDC1dGFdnJwOXX56Rao2dx4U2B6TVf8lqiWlVVwajkV Pn0NHw2UtdVXFo9C+HYTrrRk+digkHZOqS3MAcK12YXWZKyOhIpValb7PDsPoDQRvAxPn7mq o2tmHUnqGJ+DcH1loZsYXDWyPM/Ry/dGE87IRl5c2aOk9+3m8+UkDzmxm7dNrErG4OYGbHAy svazjGyFEL7d3FhuwfnYGBnaR6exTJi1me6WJFcdSWmrtLb2+XUI1x5PNJTpSWrbhCV0jM8x xg9HCnMCtMUv3jy1BfdnRyuTI9F2+qm9s4+YxytebW7MNhGw7hZewSmVLPizsSDYWvW0XhAV Lr+mN0ztzMI6ODrH1XZOPNzBgN8RbzffLDU5Gkvq6FoTW7b+eaoB74E8ffaqnn5w5RyjnbWN 1x0FwVamGo5e0VXjEEK4AWF+kKGc+FkZfZf0Cip8Ru/kNLUzKdBOWgmRntNE5SI679fcX3s0 WlKoc1hQNymBee/bDbjcHGesqqtn4932cVYZH9TcX3tEqSvFSGnoewQXDo4wGoZwqb8kxM/C 2AAdVb0AeXvivj+2rbkvIyl63zw2gznA6ca8QCcdbVviAnz8GkIIV0bKiyMs9RFpVfOPmadA 3m68XmrE490s3ENT03e63LP5CvYHoLUkbwghHXzK+phb9ZeHpoqCbHVl5L0qqznsvyfT4lzV zp57oKvvbBNd3z0FIFxemmtPC6sce7j2HMKV4TxysIq0nGtExfIUo5cbr18O5wc5GGta+yQw 16Qe9cck+ZupI8PDKqkP1+gLu88WJ9sSbHQunUbiyAWzEL4ELyklgTYo79ji2hHWqTQ91JAY ameLcK7uW1mnZ/bpxFq9zZ2jeu6ZzUOMhuEwOSPK1yMyM7OdZeYM5lT5qP33zZC6aUC79yWY pRRj/Tycwt9hmft6/UmewX4jT264DyGEGy+e9fvfkRISPK/u41tO/wSD3pQIaxMlFd8KCGnf Y8vtuSQ3DRlkeEYvoB2uevlwZrLA11rt7LEzKnpehSM86n5fbLxeH85H2pmYWPkWsy72LQ/W 5waiZOVUYqqpnIeaJonRThgJ1ZgutpMZHxvb1tyXEBd/YJmQ3cH4zFPqsv0c9PQd0xbgU15y LAPZ3gG674T7CzXR0egH3xpXTC3T3/tPF8bbkxy8XAJSake3t9DLjGcPx+uL7JCmAbmlo4us t1Lq0uI87ew842oX4fM3EEJAKYpPMNRV9MisfvjsMaPh9Za4APP7Z7+9J8dTc//NOuzzNVLB oLnhPjP+3Zr7L56s5OrsQXrzhvtv1kCfzw1RpI9r9lY9U7UpaTiPgMic6gXIKqizE839F6+e T9TF+wS52ntE5+T+Cz1Y/ojfBNxfBKAkQE3NyjqEyEmpZ2fHynDCp0yxeRncshy/CNxvCPC0 tJIzI3YzlXZosTwDunHG0qbWPhkNAABABSDDRdXawyejYal7tMlB7Iu/77tu5UBom6O2j9S6 3L7mkFDIfQT9g3A/xU9092FEcl4z83D6HACJGFV7d5/cDgAAWAFgKBGh5uQalMCenNnOwiJ7 wV2HjXx2Cve7UzP89H+4YR4diydyRiDG0ASJ8MqdBgsseIgG929d19TDFja8u2IAQF8JwVd4 12EJn5jaAR5n/cdqBwmIUzc9Yst6OK+Ol+SH2d+7ZJk+OctyiQb3b4lK6CMT3t/yB2J2pD9B 7pR9XEHeEACgb6QbK/eZhFtmTQMAYLKxP9fqlHRYYc0QAGCsNisZceGmR1VFLyd3GC/Bhtpr XrEqm5xdArNlCfb25rpe2QCwYaWlKdDloXVeXo8G91dnwHSIiZiGtpZ9EFe64yMjTS9ftksr K6XjayoARVEIExtzZw+WYuSq9ncpJ2wjqNOjHfW5xLRUZn3BEUF6l//6wDG7tpFehgb3L0or mFmkc8ymman+UvfL97xJVTULAICe4U4v2U/3KLvmZ3JqiTSVpQdqXrXOnp7nQuIfMtTtTE1z 0Tp5SSekZW54AQAA5nuLK/ykj/2A9Ctq27FmCQDbg/u1yc4oM2WrcM4jIEsAdOENxCztsKFN H9P2NuF+uvmlc/Z15T1sO3VzLOTdfHAxXYB2rCHFUMRQV9eYe+rEhRFNLknaZURV7HDlY6Ku O9ng2OdXTWJqqjkY61huRrTrPYWYQVY3FBrcv35VChmWxCMbKwBQUpB3LfLt8EIAACAASURB VB38grmuzo90FOjvVXbNiqtdAGBpdrg+Q+MwAleWzrUKOtJQnu1pEdGyMDwPQAc+yVP/6C2L hMRkrmEHWOoZm5gGkGfAMo2zjlWUx7rryJq64ZPj6WUyMnPLmiZW5jlOkNSEeztaq6E8WT9Y RdWdw+wLmazxYbiPPPP1XVxCwzAjkVQAqrHSel4hhGIAAFgGYDBGQ87ROzKF3cl2piUr20bo s4MmwTuG+9S2nHAPyQva2fPtXIi8PR7tjVJVjp1ZWGZRjf83wX2i+bXT9k01fWyyellmUq7+ 4e+69f1wvz/D2cnWAuGA23qAWaXlzYMzLCcGth01CWikvqiaJZFI4Jpk/lqiRi5huNp5sDIN KOl2ogbu4ZnVHBVM13WkWZz+3yLOv1O4P91elB+ge0/PHReZQM9LWhaR1NxHmedeRvnDUPej 43cH90caUv3R93VwY3CRExfMVPiauJrb+/LCK78A3Kc29KVYHLyGKx5Z4iSSSxUknKuCpG8N hE8hhLC7nBhqSvvzWWaA2uVTB+/ddq57/PbtxhLe08YL4140w9XyNuD+JVldG/ssVsLTXEQM NpAM7aBrFoHu7BgfRVXPcbjAIt3w9u3mDFFHWUJLcadw/wlls9rotgTKyjWKzBnJ8ZEeshc0 8R3T0+zKAJQsW2elB5eUY6sh5AVe6LG58abA9IKsjK5pbPMs9+W3G7Ddy8bMzSygivPqi8WN EZzWXXRgZhM7k6A0EZwRly6fdq8e5ol8th1NOJtgV6fwIQjhJoQFOA1Tc2RkMa1XA0E2jiEu NLi/8abd84GZWxi2mnNn64uFgaGgG3fQaZlNC/Dl1Hh9otZhdfzwNOezXcpPczQRYcL99crc MDvpywgsmZzJlXFfXV0HJ7/kraaG2rJCXeRMncjkdEaZ4sr69jn4MSrwEEL45u0mmGypqC5i tkkikx10hVR0jaJLtopNNeBtDK9dvBk6PrnKKhGyCeE02dEuwC0k5xmkw301EUVJW19Oq8yH r15mW4vYxOS0cO3G/JCh7uPJl6Xoe4JKVnHVHY8ghPDtxqvFQpShtIG+S+7HWnJ+EO7Pjrfj jQ/f8qucGuJ0+V7syvDzVlEwr4MLH/Gu3TbcR7hE+ZWtsN+aEGWs5NgJl55DCNd7s4K9ZK8r BJGTsrimjo+2vYOrPnGn+69fwf4AtIS0rH5IJgeJez693u8ppRSaWTbK1u/JtDg7hSvXNb1r 4QqP5bT1noxAPw0x01q4wHV1INbAy8HajPQMwrcQPu2MMPJ383Sv5yy28epFS7hDZnlL2wqE j0bXSo2uPjC394rlGnNSdIib4nX9lP6FOdoL6vnCi4F4ew0L58Co+K1iFa2ji5y5n2nqTHG5 oe6SmJLBKFZSUNgx8ezFu5YItwP3ZZWtTGPbWBI5WRsb4qZim0aXqHrYmhzio6HrPwEfsrxR N1+tTeOVpUR0tHYM99+8WptLUT1rE5qTxanfBMFwXTHye5mgnsox9tf3vwnu67rEB1Wust8a HWmm7tINed76frgP+ooLglGSZjhCejb9ARaWF9WOLD5/tfNX4/RwbYzRgevm8fg4rkmG97Rx NTYwLHmyvL4J1zsKgnwt1T0LGas19Nh4Dilhlnc19H+ncH/jxTNKFgbj4GofkLCVmrK27gke mkl/GOr+JuI3AffnAUi0VbN3987lYj5gaXqkzv6sUUBebD3XtV8E7ufZerq7a4Rzt7wIQF2o qqGHTywZANrG9igtI0/f2JzRhr5ktVP8n/5D4IG6R1ZTV0l3gMTX8pEZNdyM/YNwPztU7qJF wTjLVQ64PwdAIuamhjkmPp/j5qmmoWzUmRMo3E7hfm1kkuH5//WXTz7//As+HnHwrIipTzOY Y0FjNLiPDCiI/xBg7yvJCpW/ZFEw3sZrvKCvZDBU/pRFQQGPywONWZGWl1TDJqcHWVoGoDZE Genhn8A5/B3G9uF+X0lWqMIVi4LJdk6bBAAGsjIiHK+oJU9OL4C2YDcjlKxuVD3HshCYBSDB iqm5vzgJajFKZw989fdP/8kr3Xx8fHdsyURWPtQV46d3+/DW9X+elsXYpU9MzC7v3EN1eWG2 pSwRo3bos6/5tyr8/J98f/nzbRQn3H+AsgyM6uSsYma4L172pF1CMXkIANAz3Bko+6m4+9a9 W9mpT4+wuqoePj3LNSE/BPfBUHOWm8WlfXe8+iv6l1fAUld+tLvw3jOYorKP2bYPtgf3c8Kc 3cz0ohtYNsVv9ThI3skT61r4UY1vD+7TNPfr2LEvC9xfAKAmSP7Uha/+/o93TZ279n4ZbTvr 20RdNxF17DAqoqxrmPNadX6Kr7KgW/HMwlbSaXBfH4tL5rnQsQBATZCsvicuuYj74vQAiJWU tcPjCoYBmBjrJlod+QkVUVb4fp5dFRyle+b/+69PvviC5wvq0EUpq8BWsCXm31fa7ie292sB RoE9+47cQ6R01Q0vcljGDuZ4eSj8xPLBOnNdzil6dHJy8SGX7SkA24D7mdZCYhFUlqsccJ8C QCzqgqqlG4GTV0/UdKagfvoRFbljuN9XQwi1vqUTQV3gcWMljuCLvuXRyOZT+m+C+zTN/SZ2 wvxz4D4AoDYSZSzIMhf23X1gGF44Nj338OEOjVmzgnRvn/7L3z55xwfrkISNLbEPzA+DaguJ Oyi78GKuLnf28DLUZYz/Nw/3AQCUvqYkZYHT+xlJ+eoA31FDv7zGzrmFJc6q/oD7Hxm/O7jf XJIarC8R3MHx+xlCCCEl2z7a1968iFetPx/uj5X0xRgcxHT089gETmkmRrlImhMgfAghhLPt 6bFe8uYJr+Fil7+11MkvPzt5VCyg4dXmozwTfQsPw2huCLkduC/hE5POfpUD7jcXhbtonEEz urF1MxwMttXDIHYK91dHN5PEju3f9Y//+ZyfR+z5UuCyWfZoF/secUqWbaSvE5rnU2CJzY03 BaZiPjHpJJ564JsbsMDUxifWicfltY03bTgxvZDM8lb2lpsIka6yliks+vUfF9uE+5sbbwpM HvjEZuZxrdXAtelXrbYPdGMzy8fhUmNXKubHw/Y5wwtcs6qpgFVzfyojyVr4u7/845+80s3P z39W1sa1iuXulfZeotFFfv5v6Ne/2H9GSC56oWvmOU970vfG5sbrlUfUAi+xYxf28rG0+enf /3JOmBPuu2NE5Ow74SIXkW4Mssa5u0YMQwbcN0Gz3UuLZ69ftmBFdEJzKts4L30I7sO1Ny/b omV+VDOPCal/8QZuvnn1KEvvuIKJp0/pPM8bthEfhPtDA+1RUkcciseWuDu1VJ+Q46Ygmwpn uIUlPhjbhvt2oaSYdo5bWeH+ZH0CWu27v/z1n/xf8Jw65xTEPGp21jca3NfEmHoWcGHlpedr eORdpwRSF9va22RaXKi/Eqb0HTVO1sWFuilh0iDkkap6/7ggT6WoEQg3IOxPRWlgTD2j38+z F/uexYoc3CvwyWc8X1B7d++9aVk4vSXm/+YFLLEyEDnBKCDAz39U2omYOfCEwzL2GaWz2fnC qUO76QX5DuzereTe1N/37AVPVZztwH1MWD77VQ64X5fj66Bzjfnn1s2w399MHYPaMdx/+uJZ o98tjbD8Wh6dWuh5hpe95VSW38P++v43wX2bsMIE9m/FnwP3IYRL/TXJSvw/fcv8sjr+3VX7 5K7JmR3z/f7uMlvhP//ly8+/4PnJ+vbMvXsB/fPgJZxIiXTESKnHdkPIPpteQpjrzaW5zxj/ bx7u06IpWEP3CktefpTT8cppffjsBbt3+h9w/zcRf8B9AH4ZuP8QgKUmrHVYeKx/Vl62+dEv 7goe5zupphOAzcgtsLksFthX3sdNCP9T4b6DqoB0cF1L1wCPGBoZm5pZAqssGPkPuM/o48fC fWEDhGNCCa90DwwMjE0vUFkn5vLc7OTY8Nb1ojh7FeV74mJ+LdPvQOPvjq48f12tu7duWJNa OnsZFVbUljg/+ETM5T8I7q8sdZDqnYW/OIMJKuseBQ0lCS6K+xR8+ib7l3dI7Ri9/r3A/XtI Y1e/0ndOnVleFgfvi98E3LfV2KMQ2rY1Y9lfUOOU2SWwtc61srg8Oz44OMgoUF5dZCvz9W55 x9JMdsvYlYWZmQmWD1ZlTLSV0uWT0piy+b6PkuX5A+6/K34luL80R5kaZZkLmV4BmlI/XUbH LSzt0Jg1K0hXX1McEz4w0Mdzko1Tpqkr/4/D/dWVpfmJwZEhRlKaKwYCJa6ckNcNzq3irOoP uP+R8Qfcp8e/FO6/WWjIL3Q3d+iFNUFysmpX9xy+InVEwbVnszZA2gFLwNVzu+D9p8L9ZPFj Cp6+xIZ53rH06PlrDtnfP+A+hD8D7rujbz/wLJmfn+CV7sXVx09YUdfGq9frYHHrem9beQj6 zDd3rHMLe3eag9XZPqL71S+v6scklPQzKpydn8e7yBiY/AfB/c23b9aepemqyJuq+paOw9VX L9ItTio4RRfXb99KgqvXvwu472J5XxJVMt/zjqmz8mSHTqy/CbifIHVQ1jskq5nXmKnz1OVH z99srXO9fQtfPALLC4wC0/PzSZ6qtxUVnb3ZLWM337x6+XhxkcooONIynmsueuIWIqi04mNl ef6A+zzjV4L7G69frq3OLzCfYHflMFbm+I9qmLzWd5vC8oz+7jI/6U8lfRu7W3hOssXl5aev Nzbf/j8O918+ffhwiSUvuS7OyopX5f3y2f+r9gfc/03EbwLub8nypHJCwbnZsXKcyK8ty2Mt h0rlkuWZBd04ky1ZHgAAmE3D+Pk6SZk5OQl9c9k2A3n/qqqaurSZh/vdiwapY408hFN+Ptxf AWAw0UDNyTUokUuWp9jho2R5KIXkSGuh4+apYzPb1Hr5xeA+TZbnlkdsWQ+ncstEaX64wztk ef6lcJ8my3PLo7qil9PZcLwEG2qvxZDlKU2wt0fxkOWhsMvyzANKpoucAsouMp0Lpm6372U4 HFrzgmRYzTR1Z26Lg8mBzjaahkHFHdNLW5uTe7kAPV2WR0vf1auCs/Wp/lKPK/e8c6uq6bI8 vrKfnjMNKyvhfIRNZelYravWWR8hywMAmO8dLvdVOPajrn9xYnII1lLpuAi2eWaBS75/m7FN WR7zd8nyJBmIWdphQ35NWZ4Pwf0VACglTtKGaCebzI+cOjwb7k42Ova5vFtBM+eS5vi7ZXne CfdXAKAQEPcsHfyCmzmvzY90FhowZXkWp/qrcXc+F7eMiat5rw3wVF5mkNWds1ZZsws7sgtm NksdKas0u3RVJyQgt+99Bakj7ZkBLvJXr3k01A5Qua//bLi/DMAAXZaHvYaZlqxsm5sfJcsz 35YT7iF5UTuHhyxPRzzaG6Wm9J8hy/NrwH3OmOqpiHQ0uH9JK2ehk+c3zjtjNNdN31JLD1Px XuOWlWlASbMVNXAPz+KS5anvSP89y/LwiKV50F/hKXdJ1z44gn3Mf8D9j47fHdwfqU/1R9/X CR6HS5y/+Wcr/UzczO19fi1Znvq+FPTB68HFI0ucmr3LlSScq6KkTzVdlge+HChqD9O9Hlzt Kn5M2chBwcDO9v7x67gqV/Gbdv6pqTx+Sv8icB90Zcf4KKp6ccnyzKbqqHyELM8r6ua0j8pV U5/k+u1zpV8G7jNkeVCBvGV5tHnL8vxL4f7bjTdt75HlwQltyfLUJWjyluUpYJfl6SqPdkWK IkIn4MoOSSyEEMKX64vtvRGyt8W9IooGdybC8rinr8RX6LYFsWKU+oi5+MQT0E814DHmt2+o k+Es2ydhE8KZfE5ZHlU9VR88J8d5+OpljrWI9cfI8kAI327AxcJgQ2ktfZeAkoHBeLGL95wi CvofvaP4NmKbsjy3/d8hy+OjqoD6lWV5PgT31ydLwsMNJe+ET0w95F47/Kigy/LoaVsTONVx nk+vD9BkeUY4ZXneB/dpsjzipnU8ZHkG4wy8HKxNc+myPOXuSqZ6+ibZ70WAL2fWR71lz5tg s1q5hGe2E5sQLowno22MLSQDu99X8M3a68XONKSgmn1MWD0PX4dfAu4/bE0O9lHX9Z/kkuVJ UpYS0f0oWZ7ZFJV3yvKUGO77z5Hl+cXhPme8ePx8uNJd9JghjpSzM/OJp5TWLC/BQ8bZlPal 9xZc68gP8nmHLE+45V3N36ssD+9YHS0PsjBVkbNoYHuCf8D930T8JuD+CgDDNaHm9mb2lhF1 Iyy7aKcH6opDNWUljYMym381Q92a7EA7MwNLp6KRmS0byen5ySKCsawmEheUy+L72hUa5KF/ 5eIDsf0XjfPGMrzVDFRv7LumIHVOGdswOcADQ/58uA8AAF14G3czCzP/whbmCsRwfU2clfyd w18eRPrtFO6D4f6yWJyEtDQ6LKljiA0tTdSWpsSGhaUVj7CoXvyCcJ86MtWQhJGRQoXk5LHJ rXTXEzxcdZCKjoW8DHX/pXCfOtJQjzeVkUKF5Laz9bGLnOyO0jW0diqkGeqOd+D9Aw0N1cKL 26lLTBvY6WY8DiF06qvbDEPdFQCGqnGmGH2koWdG8QgrS6LMTpUlOTvE5nTQENgKdXq4ICg+ t7aqh42RDBcGBKLkL6riW3YKu9uCXYxQ8nrRrcyP1XBdU4arkf6Dn/4ibMsJ969JCd1VcIpP bWUa6gJKX2VRqL6OZnhq0zCLoe5hYWET5/gqFlfUiY6S8FBnjLFTUSd1p4a6tJifH63M0zt2 X81ETFhKTVJBHNcys/DRBsIzAMRbikghUFGpTM3+rrzsaG93XEIafYDj7ek+/maGam4lndRl 5grN4sxoE94AoWboHJpf/7GGula6CDGrNGbah2qz04PcXb3TqheWaI92G3AfAADGq7De1nrq xt4RJaOLLIcYFmbGG/GOfrGk4pYdOupO1HUTDI7tuiiu5hZe3MLiZ9BZm+DnaeFiTmyhLnEZ 6r4T7gMAQGcO2tnM2sKjpJVFv35+uK020VlaTNST0NA8CgAAC9MDDfFSipJKph45JWzUfain Pj3K2cM3u3dgchGAwe78yEBJOQnLSGL3CNvwxqsL8dERkVmlo4C2VjVUk1WYgWe3kJ2fGyoj 6x69bRQbUki7exmAoSp8bG5+TSPbAx1qyfazu3vtQXBH4wgPP9afDfcBAKAjFuVkam0VXNrG TM5gdVkkSvrW8c8/ylB3spucE6AgJhFFbBplTc54Fd7bSs/A0iO19Vc31EVpGUrZZTJHNFid mYr1cPdLr11eoRmV/NJwnwpAQ25ICrmsjW3iUNpKQu21BO+YVS707NCZdaAyKMxBWUHTL7p6 eWzr3mUAhioTA6ITsnOapgBYAmCwwgFhZeXunNM0yhT3p7Q1p7tZiF/+4mca6t7VtvDLY5rT jlcmJmB9/GNyysbYTs7tKH4huD/YVVOQ7J9Zv7q6lZulWTBEchQRQjhHJrKvmnXkRHrJnLzk VtM4RCs+OTVcFI/BOIXmV7RznKmgDDblpXha29hYeyTX1vf/Yaj7O4P7j+Za0lJsdCRsK5rn nrACorFSDzdzlK1vdgtPqPnz4f7a3GwTwVpMApPa0jrH1nJbspubsZ1xcMs80/d1tXmoyPKS hK7InlMG7mmxWcR0s9Ofi+veOibtElnSzAND/iJwH652FxW6a0oapJVMA/qGzPXVzR6iO+L6 6XMKqjuF+3D97WZ3oZm+ubGHZ34bGyBam13syQ91CS3oW+E4yfALwf1NuNyc6W1jYx8QzuaS uro6VUTUl1S3IGa2cRvq/mvh/ubGchPW2wbjgM1j7+PoRGGovpSURWprG91Qt75EV1LXLy17 kNHnt5twuaUiwlj18i0WQ91HM40pyRaqUsjw9K4V6lZiNyEcbcmNT00qLGM8hkeD5XUVRWxG oBCuzfd1+l+/pYSNqxjf2T7ypcZOIuanIw4Fo4v07K2tbHSnhAdq3jsuocoJ9+2RZw5fNXAL q16aZOR6c+P1aJFLgENAMLF9DEI63EfKip+TNXDLrFpgGOrCtcfUltJgA3P7zMKOnRrq0nMH 4VJ/rJGdjuxlFYzN9cO3HfOLBn7OM28kR1qrXkfi+hkcamVkuirexc0d30DzfX32aKq22FpK E5OR00llXdGYaY6PcjZBoCIqmY7BO4qhvCY/1V23gslTq7S3wtrydBfRNcATX9BDoe0R3x7c h8+m62sS0ZIyRt4ZPcMLbMh9pik7J5UQX7FDR10a3JeRFLpp6Bxf0b+1H3llebSYgESYxFQ3 TbGn/QNwHy4PkUg4XVmlzMq5J8y34Oab18tNBE9LfWvvOOb0nm4ICLBSktXyz+yHLEcOnr1+ 1VkYGhCdWls/+gTCZ6+ft+UbapuaevuVdLENb216roMc5hFZNPSIloxnS1Pd6Z457auUrdfv JoTL/TFIGxMLlWjm6+3RdGdNRVpO9QJc3zICffZqvTVB8bquIz6+nYcf6y8B9+FyWw7JTVfe NKtq8Sm9j88Wn7clOmhfPP6xhrpDeQZ2pj6+iV2TLP/+bLqzOtFVXk4xqopK+ZUNdWt91Pfc DyuafUT7pD9bnOxIcfXzTCrqn1mAEP4qcH96qKGKjK8agHBr4eLlw/XRfFvBS+YRhcW8zl68 J54udDcnSGuo2vqm9vcssF4BlI6ivPiYmNrFx8/fQAimCuPjzYxUY2p7Hz9/zmj3xUQ+3lr0 6nf3f5ahrqOZuDKW4dwLn1E6WrNC3L1iCkeevHtZ8MPxS8D9py/Xu8hB2Q2Ds+y56S30tTCU 1XTrh4Bl/ejFk9VcnROqtqGR9fTnD+FwfVp0WEhqcs0Ue80vXz2fbEgMCPF09okj5XX9Ahbx f8Q2498N96cHhpsKicREIhEle+KWuJSxA9O0rrCpdYBF92QwN8XbAamN8SYSmS6KEQHuaJU7 mtiqOsYvwJUl6lBtVn4WkUgkEkPdwnQvfnJBz8I9lEgkEonZGdm13QtLVAAAoM6MdTbkEtNT iUQiMcxWTUf84iEF76j4ZCKRSMwsLq7vn2aAiYkaQrIXUsLIO27LvzEiLhqtKqTphq+vY9vc XproqSq059iPR8ySRyjj9T5O2lf4954/fNOnfHyW3sWlmYWRhqLM9HQikUgM88Noi+8/JG4X FRBLJBKJ6aSS4o7pxeVVAMYHWiuSXTEGVw5JOkaHFnR1jy0A6iS1Oz8rw1zmhryqhnN0SX3H NFheBWAwN9nJQk/JxI5ITKL7Stq7IUXPigjuP2i0Y1keAMBY62iylYyQgoEXNpDVSTDQ2kJH S83UL7GbBmFnx7pqK7OJSbFh3nL7hbUdTXxo5VKJRFJV98Q4HeKuADDUVpafRySGuNjoX/1B 0jE6II5WMjszp65ncZm5LXZ5dqIrFmmItrX2DGdp2M3eGInU90/sZuyhpo6OdlTmEpNSiV76 gsKqWqaOzLI5VQ094ztBApTJoUZyZCjqyj55E0fXtIaG/paRbn+5zy5r2XiFVbV3dDT2Z5md umbo6kWsah+cALOz4+WxSAlzW38vtj4aGiGsDQLIPUxQ3pVXFIgWlTJ2jsfThxuDi3ZQExU+ +f0/TwrJmXoUVtYNg+VVAAaykzyMNJV0jX2I+C0Dx/DYSFPl6/fNgqqLegAAYHGyvxZz8rYC UtuBtWGiv52hCdLALLFnbqeweyAbb22sLWOAZs4cfztXvXunrxz98n+flsFgYxt6BuYAA+7L KAmdFtFT0bAnJiYxuujnYqUpbps53UWnoj3Dff6yJwXFrwgp62PstoxeA93QZpboQHwPY2GA OjrSXpFLJKYSiURioI2SiPiVe0o+xEQCkUgkZpU0NA5wPUPqOCi0kL93bPfXJ4SkHLeq+piY B6AwUv+ukrSBphOjj7aaOnJ37yAdfMsAXcxmvKoy3kNH2sQ1MSmOUSohOtxG6ZqOR0pmw8eh fQBqI/y0le6LaaEZbzNPCx21e3dlVH2z5hYmwexoR00e1hIjfeQCIt47taVjeAaA+YW5zuqM NGfJK8oaumaxpaWdM8srDwEYqExwtdVUljbxwSdtTZ2E6DAbxatSZsH40vduTueOibruNOSx c/fEz0oaWrh4bs0yV1uEjZV1UhljBZE60tFekU3ERxG9pC/f09E199v6CFb39E6wruDU5Pg4 2aihHIhb9qTRWHc7A7l7mKz6HuYO83kACiJM5XQ1LNl8bYl+Pk46crcV1XCNrcPzAAAw0jCQ YCF6VR7hG8zmJRxgaaapqWURlNxLXySrCjawlL1424LIYr4bHRthZyB8zzKigZEbKgA1WGlB NUV9dmtiPx8nY3Uxy+DGhWH6iZh56kxHVXpaJpFIJBJxDkitK1+dM4j3jaQNuyivYXh5ZRWA 2ZH2alIA2kb62Dlkom9aS+fwDFikzA1V5qd56V26q6aP9i6qbhgGqw8B6M+Ix5jrq5tvJcfP xtFA5Mx9oX37TXYuywMAGB7rTnK8pmjtF8ziLUsMsFTVRLm6JG8doKCOtLdVZBMTI4meUhdP issaODPL59T09k187KmY6jAvDQVhSR0Lxog8zDVV792X1wzIWVymgNmR9urcAHNr6ePnkHi/ 9NaukVkA5qgzHVVpqY5iF5W1EOi48rKumdXVhwCM9jaUFjB6hRE7KCKtpurM+LuYdi8AYAqA GLNzIipqls4sQyaGuLgaGytoBeYsLu9s4z4AALTX5bhbiArLWSSFxjBrTCQSPS2UZTTRwaFF jCdTHRpgYaKKdPAlElO22pW4evEo/59Pyzv7R9V0dU2ClYVZSis5PyeNSCQSozwCzMW/3iVu 5BkcSSQSiRlZpPLmydUtk+fFKdAR4SRxW1Ydbcp4Kv6GUgpi4ko2oSm9YGUHcH8FAEpPFbkg g0gkEhPD/T0lvz4hbox0iSQSOVxw5+an2ytTU2nTG2urp3n1m7OIpIAo2pwozm8cWaWvKlTk 4MzFv7mHTCZEbeUmmuihpyxt6U6s4FjPGKpNjTAV3Hcd6YOlFceGVA5C7wAAIABJREFUBemI HLtzBxGdWsmx96K3MsFCZfef/vynP32tEBpV+oEViN99/Gbg/qs1ONdWW1FMJvu7IJWFvhdH k8kpNGe28sbaAZYtc49HpqvC9USMPOMIBFbPSGNpU/eYpMatkmCqp7uGcdlJ4o648h0Df8bf jd2UZQAhhG8gfDzVVlVTRCaTyZkJIViZXSdlbCwDCGQymVxQSq4cmnv6gvbj9MUqZSxRT9/K yyectWVvR0NTa/vkfDZtlqmJPpzywV2HvlJ0wNeNzNd2xynw7/r6q6NmgVld9NWHt2/hs6nh tppSMplMzszLC9S/cFJGw9KWYdtX3j03/+gVhGtrj0Zb8/LcxS9oGFk5ZbW3TT2Db9/CpYHu xjBnC737F5FYclXL3NNHryB8PDJZitO7ooKJwdNNI1MT8hyVpdRuHbuotWNZHlon26KDTJDq ho4+rE6CyWGxzoYPRPSDqmdGn0AIXz5/MjtUSS4tIMdiZJGaipLOzKKlte0jU1sIBixNdTWS yXmkXEexcxpGVnZbNoWNPTMrrKxpqSExwdda0y6cpeHYhCiMyjWDkMqZMRoSe/N889Fga2Vp ETnWD41UvixlQSYTaWWLa6vbKY8h3LZcy6u3m7P91eWhejJ6yoqG8dVVw+DZizychoaasKFn ZV3b7MZ6T5CNmaWmYURl3eAcfPsazjQkuvpaW7H3MSASg7yOSKqaBXQQ+GTudYUrUsPMwjeC Ptw8EjkMY65z9+xPp386KGWZX1A29mRlDcLHQxPlAXoPRA1dEyJTmDXmkcle9gZqRujwOAYf nMqwdkFIXUFEsD4WYnyEo+p1ZGhV4xgPBPm+eDw0XhCod1rSLAYfzagr10FJQvr8/q/PXHuA 8qnpGH4MX25ACKca8D4mZ86I6F1TsI3DMcxJSbk5XkgJl6hCBqPagDA/yFpH6uwtFSUtkyAy kW70mpwU7WEijoyomxt/Sn+CG2CwpaKkiEwmk5PjsBYye/bK2EViU8hkMrmgrKZ6+PEzbqXz QWKCg+h33x/Ys1vCp5Qyzrmhfkcx2Jphh753644FOTGVTCaTyeGeIQjRU2ISlpnTdJz3fOn1 ULyTlqWzfySLHSsZZ6ePxrj4FH3sNtTZlp5o9LUf7iKiE2No2YkJQYmdlhSxDKvsHYMv1x9N 95dmReudljOwM45qbhhahnATwsWJzvpke1PDB9cVcAVZbdSFx68gfLQ4WhynJ6po6BYQlUJm 7aStnr6RpVXi9rfdQggZcB+hLHROykjBzJlMZtjLxsSFOWnc8s6lrCxCCCF8s/7o4UBleXEB OcbKxEDruqwrs+nius7OaVb+OjPdRXS9oe6UQEhklCHlZodaK2vZhUeXsh7kGGjOccfIK6q7 kAlMX1tySk6WPUJMSsshLZ22nrbxCraE+yAQmmaufqxjTgqJdESKSxqHNC5OPoUQwsW+qniJ v9w1jmAx3yWRyaEeplpWTjH4rdxM1sbamQoKKgaRCdms7ToYiCK8k1oYy3ibEC5OdNRXk8lk MjknM83+/lcP1NCmWDKZTCbnF5CbJuZW1yF8uQ4ofSXpUTonZA0cTaNbGoeX4dsN+HSivzk1 0FhfRVDOuqCocuLZw3UIH/WP5GP1hTRsE1PoySHEZNoriqoKHT2ns3NZHgjhGwibsx0dnFFs yUkKdnMwR8j41M0/pIPhN2tgdaCyrDifHGNhpChz4YYRjkzOpj/Brq7pj/Unn25sDze/fuS+ YXwS7b2HjwwyEzsrIWIdUTswDl+uAUpfcVqU9nEZAyfTmJam4RVaYsfb6/AYI6SYkHJIUW7H wtKT1xA+fbI81EImF5LJZDI5DKOufffYNSsynmYmXkm7lxZ12d4ohWPyVixO4+S0hExfY0Vp p4jagR2ucUEIwfOnhSFaogbGvu6s73lyNM7VFKllZpY6ufz0NYQQTjd0JdqLS6E8CenErXYN FKUv/PDlmRvSZr7VTZ1U+PINXJ/r62ssIZPJ5NxMcojmA0EZSU3nSDKZTM4nkyvaxpeWWZc0 FqqLfI00hWWVceSUbDKZTMb72dso3ReSMQtpWaXs7OGsr1L6OsoYA0A/kJeRumkSSf97ywV3 E8KF8fa6KjKZTCZnpxFs7/AJq1ujcGQymUwuKCI3T1Lpk4f6ZCVGZ88tfRtfHFtuXF1MrJF2 hHr2VaLX64+agmVk5TX1rWnFs8lkWxNF+QfyLg4pPexdfbwGyn1uCBz8258+u6ihFc91yuuP +NXi3w33m5IzrW7xdqy7be3CsRWUq/DeM8L3vJvGZ7ckIqiTw2n6P177kWeNP+07bBAyQhkC AIDhtsIA1Cm+PQK8Ch64L2wc38yiwzNYnYmT5Pv+662Wv/3hvjl5vINTdb0rPwipKnj9CCJ9 hEIFoAjvpHTrJ0HGnwAAACitI7mouwf27OHV8t6zIve9myfnlun3Mv79iFpQcOEIGKwaxEke +o7WjwNnRUy9mca2w/n5/iqn+PjoAzooLKJhQ8pGnfgIzX1aLFFAkyfi9qkDbB28o+qeUsI6 3kCEymE+rviKj++0Oq6UQT/mAUh1lbxyjseIDx84hgybmOFQFSlylVRgK31E2CQ0kVV5aYhM 9lU+xcf3JXeVR9RNw4q5VZreHY2VqRYSfHy7aJkTMTVLLB7rw+oc/PYQH98FNU/vzNahLNNb 33+zh++OmiexFAAA5gAgukhcPsva7lENHu0OVPRhJQ5+u4s53oMntMImYowkLp/l4zt8U8Uw A8zS9wQ3VhDRzG7w8fHx8X37/U8PLIummadSFqeGGt2Fbp3knDsHH6DM8TsZMWs0xBPRQqx1 iZl7F/QEauzfe4jv6ANUBL4HMOC+gWegD5bkY3KSbzcj799e4ND67xnuC5E9iU4oDvW2lWOp l++iupdvGUu7Q3m53ooneT5BPr6DD1DoJO4RLQBQiZU7ff6KvJxXGdfVnUdntK/uLRYH1bsa Pmmc9faXdwWIf7/nK2ahr/YdPW1VXNnzswQmhki+noosLV/UUPcvZ3aL5Ku7dZFuits30hWg +d3ug/S0S4j7t8wy1nL6ypICxPl2b/WRb9f+42esSj6mkxN13VlWxyTCywhu3tqsyTkqio4m sOzkH8z1ZrOfZYmjWhHRZexUbjA3y0PhJB/flm3z0TtnTbNmF7gtATpzvLTYKz50UcoqoIXt tBBYmAANLtqCx/extXxPyz+znKVUXYyl6Q3O7u09fF4uepZlP/ICAA0RWtdv7uMoyOXNC3oH 2/009n59gLNK2ojunjejjagjx0tLnjmEe07+me1gsqEn1ejq7q++oZfVMstirE4N5mS6y59g JueQuLSeTXoK6seP0dynDWgMNLhoXT/GNqB7ToFZbCYDg9me7vK8n+AxnajY8h2e+WCv2VWO 5Wv4srYOlqnn1ZHtqbl18b5zUHYHAL0DrT6qu7+iJfa7yzLS2NbF5VUAyJEoSUGu7rHfCwCg AJBsd/fcKc4SV+7pYLN5eWZsLyZHOwnOl3cd2c3erEtFNodkVW1krNF11nbv61mENnsr7RLY z8d3RScoqBJQRzvrnS5d4aiLHt8dOi1rW7XEuU+dbGsmcZLlqehiEip3uFgHAKACUB+melmQ c3rz8fHx8X19iO+sbWzDwDgAAHT3NXmp7BLYz6sg33HhK+gcxvGgmoJoQ1HWjzMfHx/fd3x8 Cq6VHdwORQBMjHQkO14QOMwY/XfHrijEL3fwEP4bqCU6I0/w8fPxHdOLxVft0Cvhdxe/Gbj/ iAKz1G+fPcDDse601C2OA+m8Cp82zSCx7/XtiDc3E+JpLsnPzy9hhq/qgBDCdQh74jQuC+3n VWrPUf5LHlnDC6z1VjjekjrN1rKiJ4kL7q1ShzI8LvEfUcDiqyYhnJjsDlT7UuCAJO1PCCGE b9/C0ThvDaHDvFr+8kuB06ZZeV0P6ffy89NGe+CmllbcKHy7CSscUZK0fuz5UuCyadYwfWfb +vxmt7vG5SP0Ae05JnDZIyvXzuAjNPeZMVuQ46Fwiq2DZ87ddc6GkMHiV+cH0t0v8h/+hp8r jtzS9mP5Yd5REW8iwWPEAvz8kuiUWg4AOVER789W+sCxa9pevSxq7+tzbzrd1C4e5vEAD9y6 rpvQ+06tFe54uPEmw07wJG2ke45fv+rVM7ZEjjWVEOTnP3j+vmb25kxbjIfajcP8Z8/fd82m S4e3l8cai7O1e5tHu5tvYLmdqQQziwL8/FLolEC/WGNxfn6BXbulcAN1FHo33rxKY3aDNh34 +U+r+BWwShnMkN1c5Tjnzp7jgte8e9+j8fK+WB17laZ67cQ+Zl1fX/MkTaT4GIsJ8h88Lqjn 3QuXX0AIpxrw4a5yRsmvO3yVzwky8i6wa/cZc1JBD3MrNw3u+7i7YvNbfVX5+Rn18h+6IKKT A2eZm/bXZl+2uSqf+3EfP4/Yc1xQ0KdvYpl7++54fQJa5fhP/1TPGfgYtXv2WGnrSTG8yM/P cFA9d1HUPYdT/fw1LMUYip5k7d5RFX9s2Ucb+UII4dpMT6vLhbM/Mlo+dHGvbu7IHK3llZme FJcL/PSLdFPcNxCWRiIeXKel/es9Z9Dk4j562t+8XC/FXHlwgp+tk6oBH9NJGty3C/X0Du9K Rl7YSs7BkzcRfn1bW6rXpruanS+c/mE3P1ccvIdAJLGLwqxNrzc7K5z+Yetx7/qGXyYsq4nb uWKZ0pnkfIGfpeK9u/fetMincGowTecSHWTYHgz/+SsSXiSGThqEcHmoIUWF/+h3nD28bZ2V 2stWV3OK/f9l773jmjzb/v/n93uee3TQu1S9aWqr1qpVcYMDGTJkyd5777333mEpMpS9Z5wR BwjKUkSMtloRkCGikIRA2Htc3z9CJiiCA9se79fnH8iRc19n4JPrOg/LAyxRC3LzIlMIUppo IX1ssUXLsX4Th8rZC/c6KV3w5+GYT817REsBXYXMTCBNib5q/JzzsVtUzrbWUXo/3DFyz1+d a/v84PzMvVkk5PoNL4OVnLlP69ClfB9lpg4d0VJiTjIw/AJ3z5/nwK8/LuzK9hM2NnnL98MZ Sq71Yyh5p8A2yyvtBIoh3fMCl+XHwzH/Io+2SkQNgkwiSEmCyQkBDg4ODo4fNvxyyPXGrWf9 CNL8tCpEi4NjwQQyvpdC3bV4cxnWCM6ft1kmdRBZD3l7V6YRpPGij6riTuZqdYLp1VIgPiVn ax2iZ/Ll3LzdJKkjx8NIQoCDg/OYilUxQhxBOi56ebKUNc8PHByHDONv32Z5vKDpakWwNMOs SJ2wL3jK+GjCu9JxN8vDfP9iNXNwcOw1tE+k/IEyiSA34o0k+BcN++kXDrXk4nrKpxFhqDfL mXvnXtYgSb3QczWLNGAaQRoveCgpMPRe0ufquUUyIQyN9tckKO3l/YVju7S9Y2H7wgjgI7Ha 5j6xq7uj5Q2pIDtedhHfHvysuaWlk9jL8IB6Xy+pu73pedOiJTY1Nr14TeolkclkMqkH/6qj uYGeZJEpWV5Ly4suIu0RezKZROh+1drQSA9+1tjY0oHvXZDLswf/6kXb8+dNL7pJvX1kMr7r ZVtLE+1HMplMJvf2kPAdLY2L18zQI3zXyzZab5vaX73Ck8gkAulVa+N8O5gT25Lw+FdtzQ0N z2hdeHz7j4uO3Cs29/t6ycTOFy30bHmUWWnr7GI4n6IH/+pF2yKj/ayhobn9FYHqPfaRyd2d rc+b3zQpvb0s5gu+s7WNKbqp5cXrLkYbkKW/TLHtL14vYhm+GSKhu6OVWlRjy4uOLgKp51V7 Y2NjQ0Nze2dnN5HU/aKl8dmzhpb2zm4CmUwm95LJ3S9ZerRovSRCD33KKP1tf937+kXr8+aG hqbnbS+6aQcsMDWD0pbGplbGZdbXSyJ2Pm9pYu10Y0tHR9cy86bSe9/V3fGcsazWjk58z6v2 xmeNDU0tHZRhp5n7GVh854sm+oXT2Nza+orYS89eSjP3a3972caY27K5vfMV49EmJDy+s61p 0Rl8Y49ekcnZHkJCWoYRcbWLHJOybHpedzKlJqbNL2M7CT2vWhmv12eNTc0dBMIKE/lSS2XJ 3drc3k4fnR58Zzv9xfmkuCTS/KQsMuwkQterVqbdbOWNpJn7Vb8xD05TawfTNcjaBQaa2l+/ ZnmqgoTvZoluaml+0c2wcmgwd3++u8w5csmUDepl+/Mmlg2q/RXTDLJmWKUU19Tc9rqX4Wyh PjKZ+Lr9+fNG1sAF9faQel61P3vGGkjrUQelR4vNYC+xp/vFc2pi36aW9o5uasksg9PY2vpb af0KE+pSOkRaZHAWZFcmdb9tBrve47kY1pKfMy3v7kWWdw+pp7ONOrCNz1tbX/X09fWRyfjX Ha0LJnBhj3rJ5K6XLc0LPmKet7S/6mb4KF8mvaSerpfPn7HsuC0vCaxpqomvXzOts+ct7R2v ifM9et7+6hWB3EfqIb5sfr5g96b0uLG57SWhj8RyveJfdrQy9Kmp/eVKZqWPTCa+blu4vBsa GhoanjU2NL98TSSRyGQyuYdEpM8CK00tzzvwffNLloh//aJ1QS8aGto6CT2LfRT1knq6XjbT R7Kx6XlbV99i+xOJ2P3yRVPDs/lF+F7b7F+AP425PzuNjPb10DMYMqaCJPUMjC8ZTCCPjk0y 3d47OdLfT1ykvK6urq4uUv8I5X78WQSZHOkj9ixWc1cXvos4ODo1w1ju+EAPicAYQ+gdHBub RpiZmZkaHSR24XuHRsanEWR6enKor6urm0T5EUEQBJmbQ6ZGBvvo6R1Z+90/OjY5S38vJX1f T1/fyBQyN4eMD/TT20HsH6Umtp2dmZsc7CPSUgniuwgDo09Oe7yPuT89NjbYS2BuHaFnYBRB qLkqqf1dbAx7+oZG6CeWTI6PkElvmpTRCRa3Ynp8ZIgpuhtP7BucQmbmaIuBpb+MsT3EvpEp BJlD3pHZubnRASJhvqd4InFwcnpmbKSfROzq6ib09I3OTU8OD/YR8V0EQs/g2Hz3F/Ro0XpZ p4zS36Eh6ntJQ1MT04s1gzrgvUNjjCljp8cGB3sXjDeeSBycmp555x4zMjM1N8o4kPgu4uDY 9OggmUTs6sYTydRhp5j7rvlzk697CUSGcSf0j43R0yvTzP1LTyeHeqkLuIsykmPINC1wdnpu crCXsNgMvq1Hddfi7DT3KTtWj3WPzC54dbl9n5xkSk1MIJJo80tlbg4ZHyAzX/z43qGhlSfy RRAEmZ2enBwkEPD0/nb3jU3NUGqemZ4cHSRQL6v5pLhzCDI+TCbR9jZC/9g4NWns3Nzs+ACR uY1d+L4VNZJm7qfcmxxhHJxuQg95iOEanE8/u9jF391DJo8wb46z07MTA6zTTRoenWDdQxFk ZnpyZIDAuKssyJFLYXpsdICl06wzODM1McqYYZVKT//oKNN5StMTowNkAkvUwnops9Dzhk+Y 7q5eSo/mu9DNOINzc8jU8EAvcb5f3d29w9PzvZ8fnO5u6kh343vGHkfavY+5v3BwFmRXZk0g /PYZXA6sJeOJ3eSxafryXjA4lIHtow1sN3V5T01NDDJuI8yzzdijibHhhR8x+O5u8vD0zEp7 MocgU2MDvSQ8S7WDrGmqZ6ZmRxhXN767u294emSgr4fY1YUnkshjyMwsMj06MEB64yd/3/A4 6/U6NTY+yNCn7p6e/tHlfLTRmJ4Y6Se/qWZ8X/8w5Q8Ulllgoburd5j659bM7MxIPwG/oMie vsHRxRLHzCHI1OgAibH3PQNjo4ucaTY7OzsxTMITu7u6Sf39oytfhMByWW1zH/hotNRezLHe v08rtaimeaXHKwAABZq5n3VtiUiauf9wJV8pvRViZ+NvaYrishauMdf/9kcxfzRo5v7dlbjK wAehuTI3zerwDq3sK/WtsHsDwN+WP425D3w05mZncTFyhhbe7llP3uvwEgBAEKq571ZAf25j UWjmfnHTR2gE4c5JtLPhccPUxvnDgoAPDc3cT1s0RznwKZgeH74fIaplHhhQ2LDSw3EAAACW AZj7fxmant4/n+Tu7u0+j4O9vbGZVXDhg99bwB0C3oPu5o76/NN+pnK7Dx6XUNR2d/cJRKdU dDUtPPGlqab2XJCNlRQnildBx9zGPTAy8VwpU4rgldBWlZsbG+Du7u5ib2XI/z2KU0BI0SM2 s6R+5adtAIvzEnfjeoKthTofxw4ZPWNbd/fo2KxSGOePT+PjmqJEd3dP6u5tZ2dnamkfcu5x Q/uHeEIFAIA/J2Du//0YnZt7Upp8OiaAjrWlpX9S8a1nbzVjAeDtzM0iPXXlBWg7RWnhXXzK AQEeAQHJV397uPDElxHSNCUZL5+YiLCmTUBIUHBicUNv9+gipb47I52PH12aX9cOqny83Hs3 8JsFh5y7Qxx4zxTKAAuT/V2dN0+fdpHiPSZ1XN48ICAyOPR8LWkQdpCPzPDUxKNr8dGnqFu3 v5+fpblFYFppzfNlZtEAAABYEWDu/2X4rb70tIuYmJTYPLJ69naZvzMchg4AK+LV45ayKAt5 aRnq0pJR0XY71/nbwmyyj7DXTlqI0VE2cDqV/Zi83Cy/LDRcCAm2UhRjwsjKN+smQ1YM4IPQ cjsz3UuNaZz9s8tgnD86D+9go5zExCSo4y5n5Oqa++Q9j34CAODPDpj7fz8G52Zvp9gaGkhR kZY2iKkAbwh4X+ZmkJfYzAArLSk6tvFl1Ay6DAy8miwPtNRToUYpyMpbxda8Xm6WXxb6n926 Ga0vxYS6nELYuQ4i/r0KBlgZIzx/lm5qqCFHHWcNeUX0hc75DLrAR6N/YrT0jKm2HnXcZeSV jOJr69vhmSsAAD4RYO4DAAAAAAAAwOcFmPsAAAAAAAAAACwJmPsAAAAAAAAA8HkB5j4AAAAA AAAAAEsC5j4AAAAAAAAAfF6AuQ8AAAAAAAAAwJKAuQ8AAAAAAAAAnxdg7gMAAAAAAAAAsCRg 7gMAAAAAAADA5wWY+wAAAAAAAAAALAmY+wAAAAAAAADweQHmPgAAAAAAAAAASwLmPgAAAAAA AAB8XoC5DwAAAAAAAADAkoC5DwAAAAAAAACfF2DuAwAAAAAAAACwJGDuAwAAAAAAAMDnBZj7 AAAAAAAAAAAsCZj7AAAAAAAAAPB5AeY+AAAAAAAAAABLAuY+AAAAAAAAAHxegLkPAAAAAAAA AMCSgLkPAAAAAAAAAJ8XYO4DAAAAAAAAALAkYO4DAAAAAAAAwOcFmPsAAAAAAAAAACwJmPsA AAAAAAAA8HkB5j4AAAAAAAAAAEsC5j4AAAAAAAAAfF6AuQ8AAAAAAAAAwJKAuQ8AAAAAAAAA nxdg7gMAAAAAAAAAsCRg7gMAAAAAAADA5wWY+wAAAAAAAAAALAmY+wAAAAAAAADweQHmPgAA AAAAAAAASwLmPgAAAAAAAAB8XoC5DwAAAAAAAADAkoC5DwAAAAAAAACfF2DuAwAAAAAAAACw JGDuAwAAAAAAAMDnBZj7AAAAAAAAAAAsCZj7AAAAAAAAAPB5AeY+AAAAAAAAAABLAuY+AAAA AAAAAHxegLkPAAAAAAAAAMCSgLkPAAAAAAAAAJ8XYO4DAAAAAAAAALAkYO4DAAAAAAAAwOcF mPsAAAAAAAAAACwJmPsAAAAAAAAA8HkB5j4AAAAAAAAAAEsC5j4AAAAAAAAAfF6AuQ8AAAAA AAAAwJKAuQ8AAAAAAAAAnxdg7gMAAAAAAAAAsCRg7gMAAAAAAADA5wWY+wAAAAAAAAAALAmY +wAAAAAAAADweQHmPgAAAAAAAAAAS/I/pEESsZ+4KiL09uF7+kEgEAgEAoFAf0MRevtW66/Q z1+Do4Pv/Pf8BIIMg0AgEAgEAv1VNYOMrX4jPq1GkLlZZHS1WwF6H40gyOxHdPQZ+J/a2drK 2cpV0bU20uXfZkEgEAgEAoFAf0Nd7+harb9CP381zTa989/zFQgSDwKBQCAQCPRXVSdyefUb 8WmVgowPIlmr3QrQ+ygNQYY/nqHPyP9UIVVlSNmq6FJLDwaHgEAgEAgEAoH+hrr84vVq/RX6 +asBaXjnv+dLEAQNAoFAIBAI9FfVC6Rg9RvxaRWDjA0gZ1a7FaD3USyCvPuTuO8FmPsgEAgE AoFAoFUQmPtvEZj7IBAIBAKBQBSBuQ/6EwrMfRAIBAKBQCDQX1pg7r9FYO6DQCAQCAQCUQTm PuhPKDD3QX9ZzRbVT2TfIqRVjuTcm/lAZU7kVpEzysmZtUjRg1Xv4CdS4b3xnNvE5NujeXUf ahhBoJWqdijrNjmtYiQPhxStemNAINCfR2Duv0Vg7oNAK9dcGDLhP9Dn1zcYOLHqjQH9mRSG ICHjQ379ZL/+0dDVbgwIBKILzH3Qn1Bg7oP+shrILC3X599xSCvdKo34gcq842itL3jUSCYW yapd9Q5+IiVmF5vJ7vpeNse/iLDqjQH93ZUSrnrCgFslyRuHFKx6Y0Ag0J9HYO6/RWDug0Ar 12woUi7ioMit7qlWseqNAf2ZFIYgTsXB+011jljmuKx2Y0AgEF1g7oP+hAJzfxF1R56K15SR 4RKQ4RKQ4dJJt015sVjYNAb3wtfNXU5ChktAhktYg8v0Wuil3o/83+lIzm2cg67W8eMyYtYF DkWr/9/yZyxyxo2r6rvZd8jFGSd2vz049Xytm4kMjxB10gVkjkgYqsQOxt1iibxtbSB7cKeC cBSS+YHN/cd+AcHSAqpHpb3MCoaT7nzCgbr1KDwiVERA+aBAgFVe25kFAWfSz+kLrv2XYJJX 3hLDCFq+pjC4dm9HRxkJGUHtcONMJLdu1Zv06ZRfRYgPdZCSU+YSkOES0D+mdNb7zkTG2991 xkuGV36beLQrDsn/sO3JzzE3M+UStRIyuXyydip3tQfnQ+reAAabr6thyCtgLeeADcUhhave JNDbhE8tPq8lrMAnYKjkdzvo5qq35y8iMPffor+4ud9sUBKvErSuAAAgAElEQVTLKyOzgy4j IYd0m9VvGOgTyb+n3TjLfIeO4g77eKMbzz90+bOhyDVeg2OcolaKJavf2c9GA46tZdLmMjsU ZXbIyOww8VXMfLTaTXqHNrfclDaT2akoI3zmln3LR68xFEEcMK7bVaT2aiQ5rbQQP2KLUYbZ Di3FHQ5nTW+2rPYYgpYt944naoEyO1VkDoacs8aRVr09IDQC5j7oT6m/jbmfUlTp5ROgakaX pmumZRphsQNb+uIysfZ2Pkr6zkrH934v6KcS+mSxfxRnMDh8xMlUM2sfJQ0jKUHufwkmuWW/ fs9/PvPK2xOSMp3zR5OqFg0Yz6t+HuAdpiyyn08zQj1p9f9b/ow1llvV7O8Vah5VF4odeltk 6ZOQgFCegyLC+u5yxj5Kxj5Kxj6q1lHW2SMLZqE9IiHP1iPf5RySd//DtrYtIiFRTVJh98/C Monk04vP/sdRVUtsaqK6msLGf8mrxf8WvSAg8+rT4OAwteAHsSVvGMZ7I5hzF11TG9DFw5+m zVmXa4PCTqqaBauaxTlldyZUM7x661FwdJquWYCqVZRqyMO4jGKf0Dj6he94wTO3I+lmS8zp WE3LQOovUw1imnKpW0Hm1achgQEaFtSNwi3VNK7e2z3RN59S0UD27XvONqE6Zkz7CU0a9nG2 uePJ1e/Yl2kMDo+OSNSROy4gbSh6Esm+9wmnfrVVcIecnHTWxD5QydjkmJD8tg0WFpWjKW9/ 1+Vyz8B8M/TdmA/uUF8u93SzOnpMYeOR6KCaiazVHpxlKa+KHB2eGHC+60zNYgF1I5iS247u HkIHNYSUTrqtykMPd/Dpl6tMwh8nlY2s+nC9v5Jyq8OSykLKkMKPcj5bX8bN2/Zm5oc3Hzxm nO1YvLJCWsNTav3OPEv99AdY3Xh4KrvCLqunsH5u1WeKUWDuv0V/GnN/KgDpNsEkSIUHiAaw KFwhociqG0FPsb7L5UGioI/mHgkLYR8fqqKVz5Y4r+7/YK8f6GET5xsfg7V/+joQQdBjfZ5P CkVPh4sGBIiGJ2li6n2QuTCkxag4S4aps9HqmAonEkNpo68dHmPnY6LzTSqa/BEEPTcX1lKq mBVDf2MM1r6hK5Dylrm5MFK9ZmGiJL3YLLOH1Ya4KqOUsuXdRDw3F9ZSqsBYEVWSJ89o3e5G D02taJRGfWefaBZWOdPavFIFDuBtb54SdpFeq+6tllj/oWdzLgxpNriUpp551frj28F/Ho24 dz/SjvER9vcRNhBHyescdSv9AMV21hnfrzH7WAboiHvXQ9WTHpxH1nK6Zpk8+OijFIYg3k9L 1YpytM498HljGMmp+6FBYqVX30jIYgGB/V02JdGCTifWqPlppuI+yeSClqPhl7aN1ToXGtBD E4sGeBPajbPcBXW411vF619/tfoNBiHM5r73szvG6QwfbGkFKleqTZJSTFoGvMcQNDLs2/nA MC5AMpjy6mXdR71hU+PetdlqCWGiAQGikWclLzb4DU/SCgydGHO6Gqt0klpmCFr2WpMLceyt r3a7PbyhfYreDNmCctMn+CBcvkxUKMtHr1JJgx2euT89z1zK0xd+SIsGBEgX3bVoHUR/Nub+ 9ERQU7HqnScurUOrvwz+bPrbmPvxyXnmWlIHeMUP7N++9pv1a9dw/MglvkmzLLZy4o02x50+ TIT+AeXIN5j7DLp+P9FH/T9iae9v7mecu+VnIsDn34O+8bawWH8TXad4MPc/iHKz0u2MdL4/ nhFWOZazmi15HR1/VmGvsELSpzX3cQgG9zLlSjL/Nyq6i5n7S6uGiAnXFrLCmCbjP02D03Iv Wmsf/4n9H198sYXT5IrLOfq3DtmZkcoSXN98/T3bBpG9xtcjouIszdW2bd/O/u8NG49I7JaO MIn9I/bKg1B3oyOCMls3rOX4aft6fkdh17rsu9MYHJJ57VlAcKS8hAA3/4kDfFIH+KQOiGpw yVkcQXGe8L3rX4pgcB3JV+L41u3i3CO0m0/qwMGjnFvW/+/avVv3Hz/AJ7V3/6GdnLu5ffoj SpbXo8TYCGsbu7+buc+ghwEhYfwbLCyXNPc/qq5dc3Px3PknNPczr7fZi+5Vj6wPfNtd3s3u 1mFaOqtk7t/6LTYuYKNIDvrchzokbTUV5h1kZOyqj0EK6j9SFWMY3CMTMWkFyxWb+6VmFlHK eudOfnpzPzvJ2c2Xy6Uh//7sqs8Uo8Dcf4v+NOb+hC/Sohpivl9VaruU6MZjXGu++mrNAYEt olLbpVSPmgXrtSDocZa3DGufNOU20j1R0Lnq/3QxqemqbITODwe2fPXVlk0q4cbVzf4Igh7q dr4dtF16179+3vb9YV3xkKvuyFwYglOK8+CWktoqIoDa8tX//LBjHceWHWoOqjXD9NIGms1u R++V4lvz/Vf/u477kE2yNRFBz82F4VJ4PQx+4d2/bss6ti382zWjTWue+yNI8Nigx7Pbeuk+ XKbq26Wk5nVMQyDEcrelycGDzobL6svcXNiDlKMeChy7tn33n80/0QqUktquqHnQNsa0pj2g f3J544MgaKTXeTp3l1ygPuYtvue7N3Im9FnsTr94rQ9v7oOWUu1pLn/nD2Pu18Yciw0RS2z6 eK31nhxXtd5xIORTmPvvpkY9XPLRvX62LcSgN8XMTgY1nPrVO0EXzP3PUIRqpQvB+zWK0F2D b4yZGg24YrENnQ3m/ucimrnv24rTP+vFpy5I/2DT0t2pprdnG7fAtU57MoJGyJ7PsAr6PD9y fLdm16Et1qekb3aFToy4XfAS1j36/dYtbJwyv0bd8SRTvPuJwL4Xdjcwx3WF98oIb5eS2i4l /quM8GbdEKnMStvWnkAECRkbsow34pPevm7rL19uPbJDQeXgmTqbjhb7G4mSese3ie399sv1 6w4c3ROYoV7RFnDD76CW0nYpnvXbt367dut6KaltUlJ8SXdM2pj78/KuTYbNNrG9337xw7oD Rzcxfk4beggn3bBsJn0m5v74oN9lk1/Cco1KX6/+Mviz6W9j7lP+tSuqHcjN8BHhNhCT1FCw 0GPf7e9WMpj+pn/OP625X3B3IPMWISblnJP2kcPOT73y8ckl+OQSfHIpIblsMOfeNONtqhRz XzVhPOc2PqUUn1yCT77Zm145VsDyb/yDWUzdcOatnpQSamkl+ORbQ9l3p97nP+TCe+M5t/HJ pfMFppSTMmpGM0r7s2unChheTakYyakZyavqpVdd1p9RPclSWlH9TG4lMfUmQwtLejJqJvMW mxfW4FJiatVEdkV/ds1oLv1W+oncanIatbSUisUT6hbVz+RWEFJv4iPCArXUlbYZV5zCvqL2 iDllbv10Ye1g2k384q8yqn4ir4acyjjaN3tTK8cXu4FxIreK3sjkkt6M6rbw9zD3C+sm8ip7 UkoZq+5JvzO7iPfE0sibfelVzYms5v4cBjeVU9k73+vSNyTUrRvLrepNvvxHsrcSr0GyduTj ZMYe1YyzHpxSP1VYO5hGa2RpT0r5YE4VKb16bLlJjxNSi4z4/rl5596vDvqoh/yWex/B4GYx uPFIN13BY5xs+1R3K17OqqEstt8Cw9B8680sK0aSmQvxMRGRMw7TTqVPSqiPi/wJKS73xqy7 8+05m3XJRGTdN//ayu9BNfevZfDt8HZMb0nGIZjiO7GeWl8ez/DOx2NwSHrhdR9T0aMBgys0 96Nns2uGM8qpF+ziwz6dV9OfwXS9kN4rwez9yYKavmSmlUNMrZqkG3MPZjB3+9PLick3+9Kr hvPuj2SU4qlbCjGlbDCnfq6Qpaiy/qw7I7l3B9PftZFLmPuFdeO5lT3URr6tqMLa4ezbRIbB wafc6l/8gq0dyrrdw7QxXsK+l7lfP1Vwd4C+vEsIKWV9WffmCpirzqvuTS+jDt2DucL7o9kV vSnU6c5fZtrq/DuDmeX403l1JgI75XxvuBYyb/W10wzBFHM/0uX+SBptBsvJ6TXTRQ8WbFAs g1OCT7k9mHV3elltoy6w0eyK3pRzZcEhzj/yx3ul/MG01d+ZymfaoyZyqvoYNkbKBjXO8tFW VD9dUE1KK8MnlxBTbw/l1M0WPRjLutWTWoJPLiWl3h7JfzBHiy+6P51bgad+ahBTygdyH0xm V5DSbrJ0fyrvzkA6Y9WLFDVFKcrL3k1Ty0otGX/2Bu3TrTe1amKRkXwnTRfWDTNdVuWE3AeP jFjN/em86v50lmu/kuVaoBVVqKPnJ62aElCCT6JfCwPM1wJLvfjkUmJy2VBO3cwij8XUTxXc HUil796klPLB3Kqe9Oqx3HuzGByCqZ/B3CWnlRGS4yItrB33Wladvd6dTO/RYO6DOdZia4cy mZZZb2bNBPOnxkz+3aHMMsoID2TdnSy8P0Hbr1JuD9E2agwOwdwfz61m/vwt62OcFDD336I/ jbnPKJLV0/NCv/4qdO4PD9LCV6eDp4Z98XgvfLW4g95RPQflarwXniKS/8DoojfALqXpwCGy D5FWzvsUhaARBN37SAcbtPuAq+H9Nv+JaTSCoOdmQiYHvc87bnILV2E9w2Ta8yVOyXb7P/Xi pDQk9xkqC538nbnqEY/ZB4IKO9m///d6UTMZzGAw9SW3ugJJT4ldXg/RXaNoBEHPTnq03Vdw 2PvlDlXp3Co3StjcXNjzdG59/m++2bFtueb+vOrkzgbyM7/XpQ0no/8th22OfR0hDEHQCBI2 Nxc0SPLuYRzGHv+h8ZAZxqImA0cHfPANFq/jf5VwUUsucaAH430HRoMXPJ8ROj0ZQMZ7EeZj vIkk36GpoP6+gFFqyTRzP74mcLiXWhrRr384eHqlMzg7GTQ24E1tmM/bE+pOTzDUi/fq6fMl DweS8X6jU6Era8DcXNj0iB+ZxDCSfYHDg36jIwHMNwizDI4XoceXPIaemZ3vwmi/N+W9A2Tf AZIXnuCDJwdNzQSNDPiS8LQfwxAkZGLEvxfvhcf7DIyHjg75DzBUTRoIGn3z8xlLmPszQWND vkxXVo9v71AwY8zsdMgY2YtI8CoO5An2OBZ+523ByGzI3JgficgQg/fqGQganwpbUHXI1Kgf fTUSfEj9biPjqlbLNvdDxkf8eqnLjzwcPD5D+f18ytw+amP6RkImplknhdC7WELduTBk3L+/ 1xtfo1oaxb3Tyaj2Dzdqd7zxBL+RafrKoZn7iXcDhz7Q8mYdHLwXnuBD6A+anmEcxjAECR7p n18qlFenxwMG+7yp/Q2dnJ5fh3OzQYM93kTqlM3NhU2P+FIWMKHHt5+6JqkbRfBInzeJ8NYZ nAwc6fehVzQTOjnq3z8/1L6DYywbBeMceeHxPn19fkMj/gt69MFE6WAfyevJZek0990KSV6/ PaeNpDeBFDA+HTZLDaaa+7qXn9O64IXv9R8cW/ARMxMyO+rXs2B5Tyxc3ssQ49B54fHevWS/ geEAEilgYobeyLm5sPEBn16mqr3Jw8ETM8ylTQdNDPlSAnoHg8amQqcnAwd7KKvdhzwUNIGE zc0Gj/R59xDoA9I3Ejo5GTQ6yLgVUIKZlxlNRL/+EdblPTMVPEr2IhKo750NnZ307yN6E/Be +B6/PpaN4q16gRSgkTk0Mm4SosZjYnokv432mtPVGFHx77/4lpvnCsXcR9DIYFB/1QkRfqGE 64avGUppy1f089yln2aLIMHzq7Ddviya58CGNRqJevUU93ooaPCOvMq+n/YpcqEv247OXzDo 6nAJH7ctvuXMLesO6Ms4/LOW5Lm7tky/r9YO8zks6qeFIAFv7FV3QF/GoY2aLO+1jDc6qK64 3ecKenysf3Z55v7ksF8/yQuP9yYQ/EZmQmemGWawL3B8krqtzYUhU4GDfcx/QfX6DzEv76nx gKFer47nThnam7wSNAp/WyyYXpQPqS9gHEHPImgECR4fpl7dPf4jE9S/KBjqJfT49g6HzMyG UdvshSf4Dk6ETs+ikZngyRHKXuc7OB40Msp0DQ4tvAbfUdMs69kL3+PXN7yMRbh8/c3M/dzb 3R5qW7mVInRPXvQP9+Jac1wpkfRGI/XTmvsJ4a4ygpzfsq/5+st//pONg+07FPtaFPtaFDvH VvbdPuYZrYyeF8Xcl3AqtRBH/fADin0tin2zwmGD86dYbsmsG8Sci5U9xvPjWmppa1Hs/EG6 JxtX3E4MDknKvWEhjkKh5gvcxCMh6JsnuMHc5OzjUwyv/qyUauWd6GkqRa/6gKmgyz2W0nJu vXbX2L17C62FG9jX8oj61i160DBL8NqNe7eZVOuqmpp6ZznRHZA7TjYG+6mVblZePKFuzq3X 7uqcu7eg/vOfb7784ov/+2rdt2uoPWJJmVvZlHzG88CmzRyLvsqo0kp/d+Ota1FraF3+VXKL Tkl69cSC4DuO1vr76fMie9w5yfw9zP3M8xXeBkd+WP8jbbQ5fjnEH9gXvXAYSyv93Iy2rkV9 R4n8RYnH6HTAlWReJnN/EoNrsNOS5voZxb4Wxb5+F/uJxRLqFp1zMz7BvoaDne2Lf37J/uV/ ONgZeiTqei2EJb6yMTHeff/Gnykjyf4T/4YjPjbmwnzWGJuM5d3Pm5BaZCq+9pBL9L6tsmLa Gc5XEQxuBIMr1uQ/ISIqy2MauCJzv8bWwE1SNMi2eiqP6gcV3MOfLcyV3bpP1u/jm/vh5Oy8 k5JHD81fsD/uYT+RG3iOJWVIm6+7rdA2hit6rSCX0lmvFZ9Bf60u3lMNtf4nWoFrf+b61ayO fshSNQFz0vII1y72X1R4TeIDriSJbtj803zwgY17PWyrxlKpRcV5qKHW/8S+w0o5JNUxyouH fi0IcSmdfXMW3CXM/QzMTU+9wxyo9ZSi3pJQN+lsvIHMPobBQW0WsJSPR/IWJjNICVeR5KFH Hgs38Tn9XuZ+xdOE06571m+cX95rt/3IqaWaNcpyVE6AtQL/HhT7Wq5N+z3tasZTL+caqp7Y tBbF/tN+dqmCkAukZVUaFeonz4P69rv/fvWv//v3N2vpHxxrUeyCESZxzxmCKea+g+mlM8Lr N1LWGIpbm8+rObduwR3WyWHKEjyMw7hBLEDtZOdKFtjlHAMVyU1r1n3zDdv//vNbNnbaLrGR fS2vRMjjsHLG+CpbY829jB9YW9QELIpPM5/ClFf+ItpOZM+Ozexrd3OeCDa7MFhQf1njGN+2 tSj2DcJbT6Sg703THsPKutHsovjz9s2UArl/PuDsUPtIX1l03yYU6qAOv3dz3vz3WL8Hod14 aBvjWhT7BuFtUqmMRWVeb6QUxfY125dffv0FO+pbWvAOeU6j8kW+AX0ndZw9H3/8hw3UT2ru zdzODrX31VnN/VZvJwsBpmtf+JBGqg/T4HScPR8vgvrpx7XfffnlN//+gv0bhsH8RchO8Qzj 0wa0YGoMahf73mD7wldpCxt5+0lstBPn9z/+lxK5UeQXXk8HKwEe68tOOb0YHIKp7MREmRzY s4P92/989fXX//hqHX1w1nL/ctDX4d50OkuZScEKYkcYuqN4wrcczRTTFRkTKc2J+m4din2n nXoE7mxx9UlX5TX/Xc++FrVBPFjz9Ct68I1SdzudLYyLZ6fiLuPygvr55Q3m/lv0FzT3202f nN6FQrGh1v376y//+eXXX6xDsaEoEuV3ybRdSY3PlSOMtu6hlfM+RSFoBEHPTAZ1PzZJVP7K OtWush2NIOjRbqffw35W9FDJqXYfYbnVvd34YSwX2/ajaQ+dMdEH7fX2aKQwnyxEMfeP81rI b9E15xIKMKG+xGru9z7SvhS4a5+jYVWD98jE/P/ec3NhUyO+fSUSaPejH87cD5km2JPidyiF GF545IsgaATxnZ3V9jv+40HaGP7wDeoQf0SxHaMfgjxUybTfguL4CvXt//2b7Qv2tV9Tx/wb FGq3S4H5b6y1u7Y9ktZHsf06H7Zuv+Du0N+0zdWlC67Ol0wz913DVaIVqbXv3W8abbjis3R6 H+oU2f1IbdvWtyfUbS1XpteLYjuivtcgWtlo46HMBveOFdU+OxPyPJVLV2TtfJnr/4NSlo32 OJx9Vjq4gjHSpeXBCX0U2zZq1Tt5d5hcRncOoBEE3YvTLrT9kfJeVwNOOxE21M6NG020G19p p9pxiqAoP+o0vvJHEJvydF4F1Hc/bvjF+YprRiSvnQi9O2Kumnm/v7GpS5j7nfrnAvdyM15Z R/bKhJgyDXWLdZEeG9c2trXf/PMbtn/9Z93bgpFe5/EiLiGutbSYH3769pCz7o0//FirJlk/ zj/Ki2LbSIncvk3UUurRuKrJss1965vJR+Xnl+hPeicNy7oov59Pmau2mw2FYvtx43cqCU53 X6IRxOX5/RO6KLatKDYUim2H5GIJdaeDkTJha7n1qHVfrP3PP/7v66/+y0Hr9X83bj6c0Oz5 krYYqOa+R5hihDw1bB+X5Wnj1pUub4Rk/Xsew+Cg2FCcmzab6bZ0M5qHoQhilGy9U4jh1c4r ov6q36NQbD9tWqN6xrn2JSXSZ3xEw5P/By4UG4pnv0KY2cxkUHPyPm2htSgUGyc/pwUW3U0/ hSNwctQqWesnwW3zVa/f+N1hV/2bT5lnsF4h0foXWkX3Ot3vFx635mZDof6DQu3xvGj5hHmO ShJ55OjLbJuWFnd4isAWC91W/Jvt0PfQzERgU9I+TcG1HGv+zc72jy/Y2Ti+p9a++cdfxKWu d/r2U4Op5r68f6SINTc1TFIooMieteQep6H8A7x719CW9/qNaw67GZQ3LFjey5B7XYGIFRdt cH6Q0jngHCMhKi5165UfvZFjAaVuG6QP0MK+QaE2GMQa3+5mLq3ZoCZsJyVG0ksH84d3B07V /yjbjg1sKNSvukGa1UjA+JBFovp6ga3zRW34ZZ1akmt9rU6ez24u+hxRgtEIEoIghmdMtwsy 7hL7uW3PmLQzd4TYYJarw7Zny/x7a4bdhmqPqx5YtxXFhuI9oBpp/u5j8gIpQCOTaKRERsvy mEuKHs1zR5CQsTa7G6eP7uYWvL5sc9/p2ukTJoKbPMttWvuCJinfisyGzU4EkPB6fkpHzCyO FrTPv/dTmfvBw32WOQHiFgrCxWNdI8sz9+sSDpodY0Ohvt/KeTSl0+d1h0625y4uFBtq4xqU umLxA4/5yOkgpFHeS3nTLsYZPCESdt6BsbSmqzIhsmyo779m//J/2b798juOxYLpRW0S0ZS6 iqBHEDSCWF49fVgGxYb68TvUEaGzlU54er1ylHp/ObJDOsaBMBBSF89tdowNhVqzeft2z3Kv pgE0QrSoSz98FPXtBtRe32vaKVmC5lz0etEXHJY1JnR1aGe5c3IxdpmPWzPa4j2u0yX19zL3 SRmll+S3cQpbXna5QEzMxpiKHdqkfcX33Buy4H5acz/72u8RqTfs3ILUxTh3auTo+mFdo7Gu 0VjXk9dczzyJKx/OYwiO9TeROn70h0MGR3Vi7dAXXaOxrh6hunqOB/XPh9PPliFllV3TFzRV cUo0iaaWFo01MbOUVHFX8KhIWNGh1fFJOebGBkd1Yu3DL7pGY12jM8ycHYQPH1z7DxnF07go HJJ7uzs+KcfDQJhbznifiIOMaqBBNNY5GusajbV08FGQ0+WTjfOoGKF4B9lXfw/zseHVijTy LaC28JxrdKCMlJaUWZEjU8bg9piMVGUhlUMqaFqwY0iOmrzE3s27eXTP2FymRZLOnrsfEI11 CskwOLF9t0byogl1C+6NJuXe8IvDWpoZiR0X/Ek61pYyktFYr+T6iBIGB6RuKLf0ScDpq+7R WH1N5eMSb0qo+8TPK0pNzk09GutEHW1b79MaauqHlVPcMa/nM4XWDWOuFBnqmohrBKh5UufF w09JVXnn7kMbfxSWPrt8cx9b4ecXxKUYbI++QB3GPPugUOnjimJ21zwLyfTIgnxrI3sBeXd6 I91DdNRltx06yP5/Msp0c38Wgxs4k1cdEIt19Qk3Uxf9t1DaIgl1KzuTCqtcw7Jd9QR3n3AV t8pypa+0GvTFbiaH6NbD8NBIcQFzpbBzNpQY/wRLLcVfN7Ovl0ta7pE+CalFppIbePz+0FPR EFJ0lwxqwNwlYdKceY4YiWvbqnuhV2TuP3axMOU9IM/lVsdwk/Jk/h1iTHLlyWt9abXIRzT3 dcS45fy4uPWkXFNMo7Gu0Vj7wAy540eP6qU4ZdBN1cgge20zbwUn+hXt6hulp2/FK+tjXjSa vIJUzHd6sy/XesRcoRXoEJylKnuczzDdmVJv3TjmBi4oMVxSwZRrv5qMmpaE/TnLUKxrNNY1 OMna0vywoJxc4OOQa5Siyj1i3Hh4DXl5laV17eRcsU5RtEYa8kiZq8aPJlQsbMYS5n5+JT6p oMz9FNY1OlBSUE/gTQl183OMbAOOG8YwrMN0Uwc3CXFDUb+GmNKx+dKqCPEhdlKy1lKWsWbU SGMTU3Hhw1s4hdcfiQ5cgbl/uczfxe2IoKVi+IX55R2dYePnKnhITtH/acg1emTquTshZ9L1 jdz5tymp+5jxi+qJGkfqR2PtArJkRRSNE/44ucj4vFEZV/+ITMba+SbJ7tvEbxClGcCwMFIb Y0sZ82Q0u1ubH9vJ+auYjpj9BaswrGs01tIFraikJub/7PTN+cGhZt/1VLaMM6MPI9bIzF5C xUbcs37Z/nX1i9M5VV5BMSamGuv2Oui6ZVPLLHaNLg+/2p/OtJf2JBTd82eo19U1QFPV6rBK knftVCY1rLB2JPN8hV/8VV01I1lxSWlrb+5jciImSYYBWBvXMG1NPbmzk/GVCAZHissoMFRW P6gWZRpQ5BqNdQ1KtLKwOHhMc9e2HQdk7RXC6kKwQ4X1cxjc69CwCD1dRzlXrHMU7cqKtdA1 2nUs2ArTmUhZOXcGE7OLfWOxuqpaomKKwozBCTV+hYSVnDJfXh8cEigmrithf5EyKa5BZy0t TA4eO7Zh3a4jBozm/nDyBVxIHMPg+ETo6FrxKwRaXh3/aQEAACAASURBVJhOuUuJGcmpeh52 6opHtL+4pMFRYTejaKwLNd479VFUKeOd+7RgaoGh2a6murzi3loxD04xNrLsfrA/WkLYSjny ku384Jw2VZf9ZSPbesWs+a9m60Yx1+sDzlx3tbeUV1TfohDvFHWZ2tSb3kl/nKmfpV2zebdf xwVbS0hbS1vHm9Nqd/eWU7aUtMh2u0ZLZjCWcaMxIiHfNdrp0GF3iRP68hoavNIeulGXHaLP qGn4q9tgwuYfXHjk6RiqpuKjydBfG49INVVtbqUsX2xPJpj7b9Vf0Nwf8e5vtsBidbEJh1Ul d0uqCiZgdbEUVdj+3u63khqHXBvrTUto5WB1U9ECzla8lmH6rQj6Lbdsv0WTI+6v7vNby4nG XbBtHnBqK5fTFOKOLrV/Rma9t6urWjXd/KcfDfRqO/wJ9QpnHLnFFGQqEfQQvcsesw+EFMSF gk8Lh4cfkRHky2lF906gF5j73n9gZdHqnAZX/ToGFtwsTHZ90exQ9dR7JeOziLmPRnqdZ3M5 GY7WCZ6b8/ijwugmbRgv62DRR630BZzPGj5kaEb7I1NsrvxFxw2HNUVco9Ww9GG3+P2lD5mx iib9azFHlbW4bU/p5mIoMUoZSUe1BNZv5eQJO29NMUAp5r6OzM97Thw28pabLy1WOMBFUD/c YGUzOEH26HxkhMXqYrEipiL7Td6cULepWOaUF0O9WMX4sMOafBvW/2N35GO35duv/j3txpnm O+V1BUJPK1PKvHxJJ97jgLbgGlEtftcSaiTRoiJTxEL7oO0p3bxzlKpVs5KP28hxWsSZ1bb6 T/R5vKxVvxC569DuDUdleNzClXJS5Bzk1ivLbjNwPRGeppoaf1z1MGdChVvroC+h3fZagowj zzp9qwNK9sfdwpWo3ZELdTykZyLypu+63mzuhyKI9ZVQ0UC74xEMV1Z2vLifNZeijXpNlx9l hU8M+XbW6ZZe0w035jTR3mdxhh6MLbOsbmBYsQOOLTflLOR50ZnqudSYSxe1w6w49VxlkkoZ vhJr1LuCFtDQ4PPH6hZSIlOkzjjt4pdav+Hr7Q7LM/d98W16BSd5jm7c45+oVd7kRZg/PTsM QQK6GixvnOL11PqZ300f+ziANIJGkIChXqc6rO41rG6KK6eByeFFEurOhiIE+4c1RtgE4ZNW 2zepSydma1F7bVB81bplKGiUGkwx9zWkN++VPmLiIz8fFiPk5yJkHG3YhqAnl73GHO9j5II0 +fyxukXUYSzMVIiy4VSzkCu670rddcMQxKv1ofntLIkoP65N8mLRxnsMDY46BMphsarnzwvo 6SgWVVCCg2em3Z/cMryZImDryMOrKphmvlNW9xg6VhmLlUtKElFVUa995T+EoBHE4+VTlSC5 LUauynEZ81VfvKAVarlT1002lTEjSJ9L60OTwuQTkWrsGn5S+gZcRkZ8DpG62IvaWG8u+9Na qfPbTiiCWF2OEvC0FPI9S102yeLBJtuO8mz8Sl2zuct/JTveUpqbCR1qtbx3Wz8r7Ki79mYB V92MQmrtV42uVjp1jwbT5mVq1P+KBUrhOIeAFr9D5HxYcjCvg7uoZw7DZdXv0FwiZ6nIh87W yKPOy8XzWqEWO3XdZNPLl5cuhTo4btWpAoGO/I6RtMtKOtJtt/jejf89cBzb4duHoBEEPYZ3 eprBY+AseTJJnRqmg8WKe5gcsPNUyWX8bm/Is+eZ+aVzGnEGKBMXfi1rARPN/YYBunkYXSya Lwgt43XTbWbKp7XW6FYkl96JLVuEeGKvGlS1BvaRPDqeWBSdFrPh+b9f5YV8Y/XrGtx7kKDJ UftLPtx+AdJR6QwX/ilBb3NefW/1Owh6jFr1+IB3R51OyVVZJ5lD1hr73cIOyYtyu2erZ2J1 44PF/FyEC9vfNQfMC6QAjUyjkfvKZvKc0maH8x4zvDwe2NfpWFnlSBzzn5/CdzT3Gwxj/XlP mEs0D/hOsjzvgPjWRJ1wddzjeMkVQUKQT2fuoxEkoC5LK1Bng3N5R++pZa2f3hbrB7dVEtHC 6lt3+Z8+pK/HZeIiHoXVPV+k6am9L/ai+aNeNIL4jvYbxqse8Y+SP8OwzycFHbWzEnA+bdxO zZY02OXcUKN7vkDdU+x7Xcfj/hkM011l/+yVP4KgkdlQZNDlyV31SAs+Ky3R8wh6GEEjiG9X s3U1VqUgn1/0sGBaqcP8JMyGIoPOT+4a34g7FuHMucdVylNxt56RoE+0MrZAsTDqsIy7ftUf Psi4T2+72bU8CYNdP8vJbVR2EnCOoixvGUetnboWYnHlnivZBEY8Xjw2L2XocmbMcW+rQxou mg/6Akfee4dZTH8ncz+v/PeoSNNfOU30Ih7HVSG51+5HuCujdriZJjUufsrz533mvqSE2Da5 KPNUQk7tDAaHYEofhwRE8gkYm58jJ9YiGBySef234AAbSZVM18Iuxg6m52FdHD3VrBPMziM5 C+9mXUqRQV5qcuIHvQnpdygWz2DK5bvujgFqJtleF6kV3SFhIvSO8svvkArTPfV7CvVbhKzL tUFe3gpSBqIxzVHl45iqtpOJWcoaznoxzxPKx6lVTGJwDX4BQWpGsTpBj+nvxV729LY9eiJc 52QrLTi/pv9kJFqW75iIEaO5P6/8iq5IKx4ew/RFzX2aEhNOmRhq77R9kl6z9KETEYEeWiqL m/vxyadNLNGa7tWMz0/k3myJiY7UUDXXPvVHaBmCwSH5lcSTHroymn6aofWRt6lvv/UwKCro xHGRTWtXYO63R0YlGRii5aMbs+incIzlVjX5e4UoaUZYnL5/BodgcNMYHCHCyUNdy0cxtIbe yJLfoyOCTogJsP9DVmnRM/ev3o330vzqeMYi5j5F73jm/vUSTyenbds9nG/Pf7WDqXyZnp6p YeGvg74fdmV5yXgTUotMJX/m8evzPR2tombKq3TaF/PQV+Mgt0K8jneibeDKzP3e06kXLMxd RJUsVUz9Fk23i8H1Z1c+cvQoj77al41jNfdzS5/HJWY65E+8c0Jd6iKMjTBW4N102EbQINsd S6BcR3nVvdHhIdIKuirul4OvIph7QxjMRV0zVy2/G0FXGd5e9TwmJU3b1FnU4cGpqx8gp3Fe xatoV7Hdgp4aIbgM+u/LLU30D26TPqaX6X5lct6QvYvPOHfO2FxNUDXLOv5lBg7B4AYxuCIl QYmDXAYyzjeCblK/JKt8HpNyRtPA4LDSDf8L5GzWSt/9zP0yS21XyUXM/QkM7qmvvb+aTaZZ 2kuG3w8mX6hytvUXUzzpeeFVKg7B4PrTb1QYiaucMMt0yu2gdTAt57yjqeqhg8fXrsTcb4vw j9CStRVxvhp2b4raO3Jm2S0HCzVhqTiTU01nmOJfRZyKO7HtAKesoaTeGce0xjM4JK+yLwp9 xv/c64RlLh7MMs7cNxHeJ3hQP9ujeCrjHoLBIRlXKr08dTlFMn0xhGwcgsGN5ZQ98TO1VLDL d8p7yTD7SGLudQdHbxmDGK+rkxkryAyx4jP3b1R42tnt36mlgx1PXFAv2sdTWXD/bjErYaNT drldZ2qQnJJnsUk5dvnTqTUIpqTSL9CPT9ZTL+5lYsUkBodg7nSn5xcZKSnt3LCPxzjb4Qp1 9nOTze3C1F1Lgxlz5N5uT0lMVlUyVQy7F3yNKQ/wBzxzPykpxcrUQsgw1/Pq9PzA3ulKKyoy MlPe+d99PDpvPXO/sinI11uEi0/k9GQs63dCKzpz/y4JUxgjul9Wwv68F2OBV684Wzty7vf3 uDc9vyputyWnpKuY+OpEPIpkHpylz9y/05WcXaQsoihmnuOS30lfZuX1ft4+8moe4i73z96f ZbjAyRhcvuwR5YMHlYV0Q/WD7iXWz+bjSKeSKgMT6k7jkCIcEnsGbWAWqes3/yPljTk3GqLC w5UVTHUS2iJvgbn/Nv0FzX2aGuV8LIQsfHSefYQ29D9TTXI/JCoiVoqgB1dYSBCC2N1wOuLs IWgbKBhqdUjBw7jutT/rf30DjlVJx03FdpiWeXYMhiD9ljdi+NSP7vb+A901Ro2hmvtRGJ1b JXIxGruPeZvc7QoYZTX33eoKZHzlDsZ0oYkry3P7Ji1i7vv2PtcrVN6kH29xs+UNSXHnwpBm VbTOfl1LqQKWLKlLn7kfhiA+z7IkY+x5zOI0yumZe316XxnkenMeO8wXzWzuayrtELdXLKqn FthpeSNO1Ej/WF43um/loxGGIPqxBnxObzb378Vyu1tymRbQOuLX+bvhhShxP3+Narxf33Jr 7LVtui6uqHDY5YzJozbKIxHoudnQnnvqCVa/aJsfcy2hDs55yVMOPOaBmrfogxPY321Zcuqg kfax+Is2zQNoZNht8r6gjOheiyDtikb//larq0Zf7RU57J1v0zgQ2PXE6KQAh0+x88NeNIKg exqtsuW/EpDfYxmnX9HoT+2+99ObatEu/BaOkhXd6OEFI/kmc392JuT5jePRvtJxBTaMz0+M vLR9VCDha34kqsLjGZm5qCXO3PfrrNUp9Be0iDf5rTdglKGi5muyUd7CEal6uN75NjekS5y0 F7BLMXpCy9VBcuq4IeVpsGnLtzvsln3mvs+Lx3pegnvS6t3bRtGkZsuKXOngRNOGvsBRBN1R ppLnvteyDN01zPrGF5hjwZ68i5j7NL3zmfsqijtOOCnRc/O+tLhy6riJsVABHj2wzOXdeU85 O1LUN8L4D4ZEJhNkj5cl0tGOPOHnLKtYbtYmmNfn8ezYuVlLi9/5pN6Nh54IEjg1aXc12+RR o9cAY2S7ZnrQgUOHd5iai3qkmP/+wg9BfIivrYvOmLT0BY4haFKTXnHcAWU1scRbPi+osz8z Fdx0VcbXlts9QuVWG1PVQ21Wd93+Kyy+T85MIDDboLwVjcyEIE36N2psKblMECQEQfSiNbis TWXP0TYZsv2jGypRYbJBGHvS4Ec9KOMdz9z3v2KxVlGeUz/SsLx1/pfkJ+qJAUIG1koN898+ +r2s0SrwF7I+a/KEHEhztGemgpuKZSK8hKMzDB71Lrd5oQhiX+Cwy95CJIqej8T92R2tlECp oLMmz/oDxxA0MuzWdlfd25Ln5CX7ZnwQw3ud7mAkw7ylQtNs8Qia8ZCc6TH/p1FbDRR3Htfi c4lTPvcUPTSBRl5a4O6ZX8BRl2iHeorHYfETIkV49ND8nfE+bfdU3fexq5y2vNMRhCDoCbJL e4mwm4NU+k3n54wD2GFekyHh7S0RVOXVy3SqVSiC2OfbcemKbJG1OhYYolXbF9CPoInPbB5c 16nAo8em32lkXiAFaGQWjRDsr2fKejvyWNvSk9DGFahWtDO/YTCov+KEyC5ORe39zgzpau2V d0hqbqGZ++RrakFe+xWijRFkkU/EvmK1IK/9iidNECQI+aTmPrr9ukmq63rt7A5i5PJXuNfz GhUXzu9Fdfabu8jkldm1IejpiaBGrHL1784tg+ghvEN9Do+jjfLFh+6MWX77HusXxwoHBkkn PkMPMjyq+G5n7rtUJMqEGtHMfYo8B8mqxoIiuTRzn6anWuVozh8Ed2vpCwZlmN9t8UfGfcY6 jNMv2LZ0UnYJ/xGySbjgf4WEfzU+qVPRTllIXo9z+JzsBI1ibJY/LItoqF3/ctQhru38ha98 iR+iwAX6G5n748l5l2xkd/2gdMm7sBeDQzA1bWnp4Ye+F5QNqgla1Ev9vM19ZbNAqXAms/Vs ZpnlCQGl5J6YSgSDG49Pu6DPt4vfJs8krNjtFLNcnHUMbbk88FSDfhmKT0q2MjcQsSx2jKSW llDtk49nup3zDgkTobefy0DI8XoUSwkluKQw823aJf6YPsyVYk93uw1HvGxDL7C28FSymra7 tGasbxWSV49gcCMxkWgTA8sT8Yu46pEhp12ir/ktuFf6E5r7sxjcoLu+mqyqpbT3gtEOz3HT F+KzLLbMHMLgxjJLHhnxCGlG3g26zVL4s7Do4GM/Csst19yvuWpu6sLP72x0qtiFdRiL1cU1 VFwyXW8hmPpRTGWpjpSztgc2jKWE6sakJD/Or5U0Pqq5f+shOiJGQtxVN/yiw3zzbngm3Isu n8pe/pdMNHM/ouR3DztbSUFFQbd4wZ9+Pu5a5ZVR4rFCcx/B4JBsarpdSkLdvUI6XErhjpG1 p8oGFzF8mc39FSsxNkJHUWq9RFZE9UQuy5JzUlIyj1I7M1pY+TrTT+6QoreETc6C6yXNKsBt J1eEZ87L5Z8nM5pX0xYee82LVlpkvpuz5i5ueyWf6nh6WLmlttpRbjOlTIQhvwWCwQ1jcNc0 pHwNfW6dwiHz5j43n4DSGXMMS0Wvk67ki2x3sM98fpa1De9t7tf3YyrTpAVNJdXR5guuAgf/ LLn9AhrxD8OqEcydZ2eyIjn3hrnldGSwFF6Ua29q+sMKzP0arLG+7wnltFDWx6FGMbhq3WMG ak7nfJgeqngVcSpacuf+zaY30Ff732flUPTO5r6bspK36VWE4Zj79rOX03m2ejlnt6fgEAyO kHzpnPSP/NIOCSYLhtHOOUxLQVUomhBza/mH77+zuZ9x9WlUCmO9GfqGFny7T8injy382gPt 4yorLLxL+/LJezO5C4tKPGVt63zE62Ueo8t8rw9z+YzEPkFBA7q5H+EkL63pKGK3YPeOyHFz Vj+imm6V0M6Ybv3Dmfs9vg5+Wrp+ZlcR5twMgxhcscpBMQmmO/eR3JvPY7JuMrbQzNJekpfz YMDkqTKWkt/J3M+/M5iYc803jlbgBbdTMeL7BcTMc5i+VCirCw4+KSnlqReNdaTu3l6J9adu zzLvBggG9w7mfum9mDDnnw6edsfgM1leKqv0cA/mEQjzvTfNcA2SMbh8WS7BI7InTdIXrp8Z DG7AWVVSSsNJ3nfBDIamuekcPWx12ylvGMz9twjM/XdTAL7J+v5NveJimqQCrQ7JcvHnIehl +7OMwilFOG4/wrNZUkk8e/52eyaNPVFJcj7IJyZBvVXf+wlWwl/uJ54ojyYC9TRYurlv/bLL 8kkm79bte05WuLaOLDT3FYOUBehtHvHub7Zg6JReyS3zB6/RrOcCLak6ubPuB7YqHmcoSjkz WUhH4HD8bXeaKTM3F0Z8alZbzjiM8p6qO42Nj59pZC5wSXN/LgwZMktzFgn0V6lifdV/dsYk JUjj5h3nHkq9M6HPYnfaBsiHlTA9l9B8XT3Fao/3Q3T36IpncGlzv7FYIiGQ1y6Code3LGue regJCQQ9/EjrVsT+w+Euz4mspiTxjsr1ixrpDymtss515/VxkjnHmqIzaGbKMd9wm1eMNqYF jQy7TdYLyZgqXbzliiDo4Q6b+54cIp46Fx/6IAi6p9EmR5Ej4AbN3LfIkv//9xkrF9Z6sVTd Vqqa5bTXvhrdNcLa4DeY+6HTk95FRpttnYR8MhjXg15xsV5xrvwl559lwiyvP2UywZYy9x0r 08Ttju12KdYrLGYtM839kLevROjdAGQuFBkyTbEXDgpSrWEpYcx94qmY8pa9XstPqNvbZHNR 73v3yy73CYFPLog7H/36H5sPnXno+WrSF1coH6HLHdmGJi24rD6guW8ZqBhVxnSxNF5RSbbd 5/cITRxbovHM6zngVthhL5MD1okL5uWyTrHPduMg9ZgK5rvdCeb1WYd3btjgkuf6hPDW8ts1 07338gtyh1ejSYtcdIGPz0lHGey0r0bjF7zakHYE7SvogGVyL4farO64cnDzCQRfd3jDEVuh CGJ1KeB4oINYFENfbt13aOpZ3hSvTO9s7qNcTmnlP2X8vWt1mlywjnDR/PfHjrfOitoJ7XEr 1itasLxTXbg9/U9E3HvD16hvVCiCuFWliIR7CPklMXwK1Nj+9pKhqE7jO2m8vwgcS8vSZF0S xUpoTyFbM8mSAfQIw83oFHNf9cRBk1PGv7+xdoeKZEEbsT36FzzxQyEIgp7oNa/M5xfYsie2 0vPFMBpB0P3N5iU2a6SclMPTF6zGHInYIF4RK8NnhMApph7Z59vtVlc4ZJZrt+JZoyXURSOI 3x839CP0aBlotygZ73eKMyh55DoyQb0mKeb+1s0HD/0kwpCrVmj/9wekf6aZ+wtO6WFWtXaY zyER33mD/lOa+/hKc0zIVu3slys09xWd96w56q5VtsiHWnDnA4M4yXW6oSoJhQtmMEHwtOdh 8XjPbobnCD+SuX/TfxfHgUOnan1eLviGFUHQVHP/ey1Ppez5UwTRCIJG2tTOxEgb0c85XJYC SS/sH5Yxdlkuxv+I0LoDiS99Ole6Mt+qv4+5X98ZHRcuuZXjgO1vnnmUZGvNpwvz5XeyH9a/ YJO7WILZz9vc13WKV09i+iWzud91MuGkxE//+Obb/7J9x/GfNQu0VWyT1vXUqvHlNxIfk3JW YRfHf9fNF/XNZsEf5bOjsT30rL8Uc18pSg39B+vbKxqSEv22SWT557zG5Oc6a/P+f//6f+y9 ZVxbabu+/e797mc/Mp3pVDN1V0opVgrFHYJLcJfgDsEhBEhwt+AaWFWatrhrSzptpzadeqe4 u7P+H+IhFZjKzOzF7/hCcuX2tQLnfa/r/PGHTexauOXkUQlv8wvkxwue+buh1OXtDErBTxeC v6K4Pw+Q7tmpCp/c/sN/fmTbF9hGYYxp3K8A6W3mNbzoRoRR4p1VMvq7mPXl3L+cY6wqvu1f G79nW+8W2An1ePM8EOgYAUowElK+Wj4NSayFvMlkNdRl4HOJ+yQQuHk7xRexc9ceatv2/3RY USHqt4jKuaI16vsM4j6IT4230hXYyQvfuUHfIP1B/M0/JO6zkHuhztdYZPMGOdXEn6NWN/Lz ifsW5sanXR6y8SxNDTB0TYKHvyyuex1lw3dk/0///mEbu4k+uHGLgV7W4/i1Vb1Q0vYoPg8j tG3vDtpluHn7xo0b/rHTSIlV3PeSl41edWR+FiDdRcJdTAOuhJBAqrhvpeVM/pWR4axr1drH EdZ5D2JZ3/rD4n77IFAcLMpxbPN3m993IfA6tPlcBoFrTfE+hv+Uyg9a7SFx48Y6c+5fztR3 SFBybWX7rr+ZgREqx+Ua44u/R8blawvZO7TMfKy/n8Qni/tYA6NYFJNdAYu4/zLtYrTgP7/f +sMWtsO45cDZoza3I69PrbmRnybuFzcNBaEcpbk2M1S6bcP3O7fsUVTJZivuh1lYepm8R2TH BTjr6RrJx4ElTAL0DED62UpOWd2OLu77m57nOfj9v354z937uAMC18W4I/X5xP0qpI6HolKC N+u20AxA+tmKOec+oXU0FhukIX6UcWq+/+GHTbs4eNcl7hM6ZjLKmq0ktx7cw3hL2fLv/z3I Y1rI+sQAsSXWU3PLth3UsAO7TmoqJbyNrp4vZtH3PyruX62ND7DeY852Ib3FRmQjRJ0dOxay 6C+OAKQSFWmMFaY9hU2BMwDpjqU019FtG9/7/SsebZf2AhL3PwAk7n8MLAiGTY3YFvtwqhz5 DgbbQOU/m37YfuyPi/sg7vVlSXyUlHsF+6qfA+KeZhynbXRptmwPb6olW+//LwWt9mcBlMOS jOI+GNjzWD9c4J86IUjiI48WVnFfPURTOH8BN7SCA0Ec+MLq5xgOSo82//OHDf/YevKQ2WXc 69E19qJTNc1q9z/+82+G8dnKJcaP/QVHTVGCW14Mmx72JTjukef8D+Mw/vjdj4I66xD3w8HH Kj7WEvbBxk8+1jxazv3020yvfx1xHwS9SRdlnHhpXd6wjfuEhIdh7yB6ZjF8eY01Pr2hkmi+ R4uAezXygbBwEDRN8FYIDTH+ddW7y4thjxJOBCYbZtxes7hfqP7/G6e6sJyeBkFcfxviKoZL i8Bm5bxH3EcvzNnGK23l2/mvH7dtYFgPVHZuhGmqAK3eTEV9RNy3JSbwiv/jfzfCNmxfXSBs wzE5AdsCT3A5DHyk7GUh4YQxWTU4/vOzCIc159zHgSBu6o3TnZDdVpnu9U/dm7KE9Xb/8z/f bzctcevqQV6NlzaXkL7K7hGfzyju+6cYZ5GYXl+XuB8Ogq5lHscV9v7vD1vZzQtsA0xWLJDA LJv22dy+LMuF0Hvx+8dS3LzUz0mBG/havCfAqyVHNdRAogzEja1+txWekyBvgGcaq4kX9h3+ Oy1yvJpefbDeN8aEQE4eei++41EX9rkSMDgZtrj8RQx1aXyauE/OuW96k2krjkXct7kSxS32 geWtKOhYvI7MPDgQtK9IPafMUNRhSV6zFHu62/Ajozr/g//1r39tZXupwrbxyQnFPMSNMOxM k8V931RTVnN4ZgbatLLcj2/W1HnYHbwEhr+rV0u2P7Ld3IRmhNB73zIT/v/t+ek/m9lWfWD3 ITl4xe909wKquC8RE6ld+wdmjVHcZ8G/vVDLUnTDdk2Fxz1eFOfWT0vL87pMM8iX0wjvyFbc X2wwCPfnl0UbfS5xf2kBOzPqPzpNTe7/fnG/u96mNOTQ+sV9/QABntx3/m/Yv6vqeuS/d2z7 bst2djPIcfCEg8nbQfpO0hcS95vTRQRCnbtH3/eYTvDUCDJCnCetyo5pL2qd4j4WBMNmxh2v xwnoHmf6a2fLps3btvEkQuL+H+HKswGgujHIU3/3//z3vzbQvGp/+nHz5n//z3/9L4+vTsRj Nv9//uXF/TQ1jnMKuF/QF7vTK1ZRNYBvmFlPgmDSEqF9Mq+6O4NaVFzmJWc94Z18wXTX308X 9x2sNslnR118yaaFFb2ZtaMFneQEwX8JcV9DyQBnnsNutCu602vG89sWvpS4b+guqJIcWNGd yq7qzPqJgo4/h7h/a57QPJRRSWtbV1Q+VnT3QVG7Zu9La1uHjOJ+KZGIslPZuWn/Tg1i0KUR wmcV90s7Z7OvdCEltst41nldXhXw1cV9Pv1Eo6h77NZYT3rFUH77wnsca9/Hg7Bob7GDp/ld nwaVUIu69jA9xeOcsJf2X07cF3FRdbkcxvYCWrp2zwAAIABJREFUrOjOapor6oTE/Y+K+6mC /4TrRDag2Y1hRmVfZuP8e0XbD/Bp4n6wvaqgrLGYfTlDpV1+gSGKPO87uf/ZxH1FkxBE7Hvu 3lUjea3zjFfWNxH3k0JspKX1zxpmBTO0LRQXpy/LcTZkPeJ+SlaZOfz09+IJ3lm/UAt8kV5R pS8mp2y3Sty/NVfSPJhBr7oTm4EW2rpb1LkrgCUn3rcR9+WVzJOQ+e+ZwdqJgvZFSNz/AJC4 /zEwIOicY75Xw1AMlWvf3e1LxbQkQlz/i4v7HtdDOJX3/c8/vvs3zZYNtvXfP3733X/950z0 z16vyJFM4n740rjXaLWQOg+/bz4inVXcV/SFcwX9Qk3psxg6PxFA6RFRDucpwONgMDyNW1xe Yy86VdOCBM/Y6jKMj19vf+D4PG5phRIz/MLpotkPpzUlEwFbaoxPd7d1lhOvm+3fW9wPn58O HumjjYzvLzc1UmyP7JVQuPrcf62L528k7tvFKx10Q2vmdfkyLBsGBtHTc0zOEJ8g7kua8Aul dvs+YVdgz0DgyFTYFxL3l8e9pppF7SOQ9UStIpQA/5a9cgr/4PU2unZdsyBFUd/NZAbErd7I +bOK+7we1uKRLe+Zl4Ggsekwpk/9+cX9Rcz0WEAfvRd2xFRhpPxR2RiXt8N/hrQ8nyjuS5gJ nk/v9n3KfnkHjUyFrauRoTOTQYMMRTUXyqF09h+1M3nZhwZBHPjIqC6ab4OaeuvPHuyWhF/f QNDEAm55hV7mJ4r7S++smpMEOWD8+Od+v4OotlwRd/ghzQJM9zhlx6X3vmWu1j+1Im2v3mK3 FHv8egZYtki/uLgfPjfl1XpJWQXGm/fS7nfyi58m7i82Msn3LLwu1Qz25TTCO5CD/7i43/cw qBS5x77IpOsd7bPsxf3Hly3i7bYYFrz6IuK+lg/PTucSx/rH7Gaw1793hLqHBOLAv4m4HwaC bpf8OAwR/OaJNgz9taosklbdxoOHxP0/wpVnAykpiWYImUPwRIfwS3QzuhjAK8ZbREBX3qwk cLUB5l9b3J/FF5U7awhxu3WFEdd+ynItlDS9Ss6Kl+CQ1w7vwJJTzZDFfSkUPKCVRU5lSsvT 2BKMCeY64eddO5HzkVqmwgN9NRSUBINf535yKqGvm5ZnLNzVRNU8TDPhwyLvTF7lHfNznzct T6ebPQquEmhPBNlkSKBBTsuj+J60PPjgL56Wh91oFNeRcBZSXIgss+Q3a/oso7gPtPVnXrkV mFAVWDaY07IAsIr7LyJiExRPquiWTCTTU6MsAKSXzloqalbJtrTsMYRij5jryEzWXhRUvXCV 3yjtWuPBmmfms6flKVidlieKnJYnZbq0pS8vyU4YHm4Qdof1slo35Zf9/L3OaOUEX5mjL+n2 IaAELSbhi2AV960lhH2srpMzZdGgpeWpjSWBVHFfTcG0wLOKpbp3GdcIUsddnL9IWp5JoLFC X85Iw6nUj7VeZlofp+ZHcnBhUYVvVqXlKXa1Rq7HULeZnJYnh11anhZjcbZpef6c4v50NrHF hGc/PKgj8OZnWmNkPi7uTwGkZiNVJy2HYt/yYYbX30ZEx6vzKaqvXdzPTYt1cPI4578qLU85 a1qerDBrRdMw+eAnn9idzyfu9we4BhkYsU/Lg6Cn5ZkHSC/ctK21HdLsL3TnM+j1SWm5lvD1 ifu/hcamK4o4Gue8zmieo75I3VSwXyXur5qvwopWrPH5k4h82wzmv3w+Ku5XktPyJL4vLY+Q KDawY5HhrQ+L+0sAaSzEVgNuFWeQ+qGtI0jc/wCQuP8RZv3B5ypWZuJRmVZPehj1NfuqDFmz Lyrur2BBkrKfJZ+qiUQKgy1beblxUbqK27nvtWJMq34LBkEWcR8HLmKWR1zTDPabeouauIgz iPshr+u1Mu1PSCR7Pl2V1IW9Ke4n8vHP+r56qG/Hx4m9ZP9ggHZMDwuCbpf8BHzt15eWxyDK gs/SXAlgzTzDyrcW91mZG3a9c1UOwXEYV+P56P2SH1veNWllOhzY44h89O4DKTiwIOhQSE7L wyqR/KG0PAXq/y0XYHbtF1YNdx1peZYW/Bv9jtkHqyc2vc9WYVVRHxH3A++UKWJ0TjixawbD ygkHJ6zx7NPy+Mw9kltfWh5w0W9+QM3BSCXNg8fVnvccXKwFt49DSTbQgycgRFwvjr3b8J9P 3MeCIPrnjPNoLzGnSz6f+qnPJu5T0/K0sEnL8zjnHC5Q3OUqa1qeTxL3V1U09IsBgOHnUlBv ehs0sYYPrpnPJ+4H3i6SD9HjcGvB9a3/fvVJTPRYV2QKix0WufTSvx/EgRP2XVdk6L9+Ap8o 7oOzgS8adf1Et2glWbfcVMf7nJXVkb7YTUvBj5t94/A44iCfk2E56RPzmH0+cX9xFteZonGx wegOq5WB370abe2NZzJe2Lwmv/KJhrpD9vmhElpKZ8pe+jEZ+y7hwNfWcWYChkjuyI5gEAwH QdyjbNVAnxO2JRR/XTLTL4N/DjvJ56Jy/a4XU5PYifs9dwNztTfp4w3a3uBA8APivndVooab KmfSi7djSWsfqw+L+6EDD8wBy90q0bZNz9+fMYiB9Yv7016jP8vBhSUyv7m4v4QBX2sHeEj6 RxoxpbcCXe5UwHW28WRC4v4f4cqzrgAvNwVRTfGIPuYs8wsA6ZG9hpKUeoBexjDrv4LfSNz3 NxU4onnFs3SogAQCpNni5mchgZFmXhe9C17SFPBPEPfBoppHsdFeogq22oFN2GsTjJGZZQ1+ WLxJ7JOC9jWmTq6/F5Za55FA97kFSCDQ+DwzA8d3UlsvihRNFl/IhrrCaieVIkwYg5teJKXn m+q7a8T/Fl87C5B60/JKbWT0hS3zPa70MIlcdXfDYkvtg29gqinpofGEYgc7XS4xH7uciQy6 xDMPkB4HY9Jtg2/4lI6wtPYrG+pmF+dY2rpIGcbb5/QXddBFjZKW0djoKCtsTciFfoAEljT2 x3gbqRjEWSQ+YtApXkalxWvLyhxYj6HuUGJSmpWhtahJvvfVmRx6w8iDk+YS0YK5DgKkRYDU G+HmrWsZoZP4gGFSniemJenKi2/5Y4a65+QD1TC3aa6hyRmFzl6pNri2eKqSiCfUYhIB70sg Qw6HmaKaO2h9fj6jImv82mw2mcR9lndZxf1xfMFFV02l02Y3/K4Mk81OCW3D+EyMnJiBkstF NG2XJS1QW8fwpFaiQ05/cSd1Btv6s0ouKp6T1sF2YVnls896cl/t/H5BV0m3ytCbFL/Z4ubh 2KgIZQ0jbdRlzHUQuDUNVDYgjR0UjaLMkx9mMV6DDW9ycksN7EsDr/Vlranq4jwPB4f9WlcT WxeKSSBATuodi9PXkdx/yk6NRdy3NOU/qiRuVuhLM9QlzRQ2PAj2c9SwLnbLfE031BWT4+cz V/GqCq2hqZ/j+MvVnu7usmY3MeVfwlB3ESD14Pw8EXqeql7VoTWMUulofl27u0OYS/qruBoQ II3kVNSbyerAPa8FXBqkl1Be7+diJnBWZl2Gus8jAiMM9AIUEp4W0d1HZgrr7wb76suqJFrG PlllqPt5xf3fXGR2C1oXuRSRezQHkB4GBqWY+Vz2yH1LDfsUcR8sbvw9GqujoOGJ8O8Mu8FY yzj+UrOPf6Jl6luKOe2aqLubGOu17wjSOvlZagsIkEBCyzA+I93aLdkh+V5sAwiQxgBSqdp5 Sy2naxialWstKSQyRllOjeu4ouraxX2goiEIHSSqEexUvJDVQn5xJK+yzk1H+/Q+JkNd4Go1 0gEloR9imfiUwCBJE1qG8Bnp1oFEf8Jbxq0grL+3loaeWMhv1G2D7mTCdXvHOJ3we2m1a9tN T0/PtLdylbapiOhcoqb1H8mrrnWz0zkN46Ya6pI1d2V1xwI3+qQ8j0gsMlBSE+B+T859Uztp hXCHy1SL4Io7kfF4fbc0Z8JSVgsIkG4HhoWJnnJ2uL6QRTHy7ckGLlva2p09xC9uxSTupxfd RCdd9b3M4DZMmi642RqkzXnG+IJj7iBT1QUZzlbIw8qFtB7lXLsbgsbp2BCCbw5lk0CgtTuj oFRDUlM9tC2MyYz3OS4cq6frI+fekbraUPe94j4IkMCs/FQTS2dZ83Tn/IHSLvojiUUNfdE4 jDm2EXtlCBL3PwAk7n+EKR/wjoS6vERsmQP9P8ZnFsR8UWPlUxJfUtxfWcY+Sz5lYiZsk2Y3 wPzW9O8ud322ndNTTK7xGANXifsgbmUF+1uFiKf1KeFThxQFaeI+bup3u/ZiUTUNgbQq7xfD TGWO1cjjPM9+MXHf47c7KmrbTiXXez0jK1PzwcvvLEuTxUxEDyJM2Yn7hRxi6rI4oks3ZTTC n1Wp58VrFN5wfA7iyI81dCaJ+uqfM8JaPABxNIdJcDpw+b5+Rrx6SYPbr2M48BuK+ytYcMC+ jmhV0eTOtFCHnB5ekhHnOBXfgnq2xqqn3to25gqLip4OLXFg2G3CgmDA41q9omydrBpPis/t BflYHym3DIceEEfLST016Hm3RMDGRDTpkuOTsbWK+/YFat8Jq3HZJ5s1PaXLuKOPLa+kyfui 1erWYqi7shTW36GE8xFyDNK6SGLS96cGve+VysaVkg1XGYqKP+dtf9a2lJZ7xOfpLaPcSJWw C679YxgQxA3+anotkVtDRy6j1p/hyQYsCPo/qtG9UGJ4iRRAGZxs+VgfKa9Ljr20wZny7unU jrc8cHzTOgx1cSAYsjDnGGdw1lFhO9z8rF6s5VyXuCLPaVWhPYYeEt6V7DcwPkXc74jm2SWj QnxFyT0yNeB9lyATi0XcuI/qAXHgZxb3cSCIG3mgXxQtbGovl97ox3gYfHkx7OlN1ZxS06q7 vkwf+WziPm7giXF54lmEgWH9u+BRhnoHOnSxXgLeEVo1z5niPyrukz9bXmff+htT2wbv6BOC TnPp6t7qDp5h/sjbDsPLaTLocOXwDOsnoyEz72nqJ9LXrFnoeYLX2fp2H7ko9Mg7x+pk2chk 0+anfuRMTZ8m7uMGHhtfTeDW0pfPbAh8Q39EBguC/g+rdC4QjK4ypgv/FJbCwF9NL1bYVN9l ctGYfGNxI1WQm1em6jV51fn3/WKUr8lp4qtJeMBkiwqOuN6pMMjNNGrqxU0zeNV+qrgP4iaf 27WhdpxGqIQ6cjgjeRUCLJi8eSf9pm4hbM15XKP0au4xN/K1Y9c1bWwm8tcxDMMcfT5xf34K dxXJZ2p60qfQmNGqePK1W1XmORl5+bpud8oa/URxH/R/dNMozuqUjrNEdqvb2zEcCOLAubDZ F7YF3gKKilwOUZq0jYTh+2YpwYJGdrLNfYEUF+DJwN8qTbxl9mmn6LW9Zr7S1i/uBz2oQER6 nnMPtnw4MzCfuvax+rC4j5sb8nhKFDM3PheIt+pg1vf7H9nUlqpFXXEbZbjJzI4HXrXaaeyn mtHqR51Q99YyjdRkvaImFDUs8Fa+IsaEx63Zb3AmHARxk68cbxdLelsc2n9aJOGbi/sLaPAX BQcjCd94i1e0F1/bNF+QtjE6xbuNJxUS99fJUkVNT3pUaYCKnBzHIQUx1E3X5AfJtZPFJJDQ PJhVVueXeF1PkZ/rnDy3cbFf9rOsjkX85VvYdLKTXgnKTOrQefPzxkmoOCIq7gYqrjO2epQs +pR2zGaUVKNTiKg4Iio4xl5H9DtuJy23PFQcERVX7ZtyL6V9YbW/30cpuHEvHGXFwa2j7Jru EEdExZW6hmFlzkufVQi1iL+XQVogtPcnZlc5GslJqtuIutGcbIfSL3V5umDgfKeEHIrtMl8m 184CpKnCepKrkZ4Uwl/bI5/RYs7aAaWoaSXm0Z7bskaN5kqeiT6S67y7OaN3a0i6k4Ull1am R+nvlO2H1kEg0kRKUfvoOQtxBIZu9BocZ24bIGp6MbJphqJi1P6aGRMkLGgC98BbM5rg+aG1 dOykTVPd6KfRX8bnpmpJKIqZlyExjO5/ocpwfQn9VKuMXrKxbRqhFZNERMURPcLzzeHHj0s7 y9oXoOKIqPgKVNrD5LrJYhIIkBZK2voTsioDE4n2tpZy0uJ7lZOdI66i4oiouKqg3AeJTTRx cDyn8mFYHNE7joiKI5oZaIsLC542J7qS/YQzSNgrQ9Tx6Y6IjtfTMjtvnOwWdZXWF/fwIh1V WWFTvGv2a4AEAp2TwLVSMy1nZfMIU3qXY/SMDLkP8+zefvqsPcEh61VK3VrsEOp+xkWGyUjp yTtfsKP7J19ExWGUFfXgyDK3Mmokodje1ltCN5RhUmLNzPRO83Fv/h8BYZsE+8LfEutAQvt0 RnFlcDIRFUdEBUbaIMT+dcYZQVlFNX5p91M6FotptbeNAlnRSmLawnpBBjQjX20tMVEjuP3F MKqSGIlGIRSEzlhQhy6OiIojuIZi4ZJqmsF3Mdc/fR1OZV696+OBkueFHdcrMUPXhJa9Tm8F gdvzQONvkVm1fsFobQOTfUJBrhFtFBfc6kf4mGBBSSctnzyHOCIqjuiBKzYz0BDVjLRKfEA/ BZ8WqKEks/2MrrBJsntUOaWRYZlOTh4CWjk+F3oY1b2sSx3h6URUYIQ1QvyfXC46ngWouMaQ wud41rPbH2YJII2nFjd72ZupK4ryqQXziDpp+eaTG+kWVqCjIn3eLNsth/5YQ3pyrLGhnaRe mEUc0Yu2ftApDqbmnGJoW8Kr1DXUDgJXawO8vM+IORhFUlyOnf3j9DRk+XiObt6tcE43xb3o OZ5y8rfWztFR4IS0sLS+nMslexxlBl0wkXAJW/PEJzEUQXYcIJVpwvXOccmKqTqroogeMeTI PKR7iLJKgG3ZDJ58hr11uOBqh2/CdVQcERUXb2BswrFNEY69SO57QPad6CqwlKzYNr5NL22m rhmMorgmL4+FJnUBBxc9T6Jtz9ysdHNxk1V1UUURPWNpyyzfCY0S51dRD/ol9AYIkMCSxr6k UCcpHR8tlyz6PcfFDS4vsucY/9ZjVoYRVRjiSM6qDbwP3hur/QNC+LSw7tG0a7/EJSRMUVxF K+QBRSW/PQc0Po3IrPWNyzWzdBU+DleKuORIDk5sDMh7kXNreY1ZlSgU1r5GO0pzS1orI9NQ cURUXBkqzktGXJtXKdoo+jG13nxduIm4hCUipSHsxlJ+Owg0vEkrvWDn73x8J0LDtdgXeJvR CpJNgO1NDOU1gzQ8mIxtrV1R8vIW0oGPE6pm1tzIphcZGXHypwTOm6UYYoioOKJ7aJ6ZmjS/ uJFKQG1INUg+uW+vbaSICNYKoFbqE6CmpXHixJk9O/kEnC95lAzjm0GANF3U/ByXcN0vjmii ayQjqylFn+5GTPHLTPpZ9cGk3HwLbTVRqyu2YZR16BjkI8ard/oQjzhDWh6ABCYkpZsYG/Nr 4zxjymm9dg/LN9NTFdGMsU17zLgNk5AUr4dQPy4T6BFNDo4zsbXi4zHhQdbG3hhb28jU3AoN xsqJ22tFX3WmDrVjkIcYr+j+zQdPyrhp4m6Hlw+Vdj33cdRR0vVTprv+RiH0zHiOcB3Yt/eI wRU7/Nu0+jmGkn/2c0fKSegJWlEHx80HoaZyUskOkbaQ1ggCpN+iEuI0hTUlXK/aRxBRcURU aIa9rRWfiOjerQc5ZN0R0Xdjqslp8UCsn72GohSfFeNlVeIcjFEQVdYKfYxlecjjcoWPnT0X t45S9FUnsuuva4i8mBivcIjTxXfpJBAggcX1vydh7ORMsfreRQxrLFJb11XFLN/rOnUXoeF1 KqEJFUdAxXkKnDGUM4yypQXnPE2unmSo9/ewMJy2lpWYWapX7DW6mXZIjjZcVMi80LvwHSTu f4C/jLi/hAHH3LoaLCqJJsRieIoP565dnN7J2sVEE2IFsqELNUZVBOZHfd/dsyQSTYhpAjoK nAo6EmlUQ7PqW+6/9r73ACx7ZgPAZ4hQDV6nIMUYmjFahJCD6aHTnLtOHj7lQbRqfYceXasD LRg6M+7zpN6k+oZJjt9pB3Mu9WATItGE2O7xeiAEBEOmRj1uXzMOU9ssqnhazw9R3eDwZAw3 u4QDZ/zePbGvLdEod9976NRJHZRqaa1Ve4P+tThOQR5Oc5RSTq1d8yN/8tltwIdDZtuGn07Q xX0QDB58aZGH3G/rq5nAbGSajRP18JJwzXZcU0coHrmpAnYGHHRD3SbnX14HMUf6dj/WwYgc RAZrJRWbEIkmxAs65XFCJrpHeA9vOyd5xinfpusdbpo2jOO+i3WyZhInjf3kY4kmRKLJtXLj IPNjBsr8filmd2jFPjG5HiGC0D4fzGgyWapdHsitqX3Wt8i2cyB0Zsz7cZ1xtu0ePRtx+3Sy ky0WBP1f3rMlBIs6wvfrJJheuO3T895/+9kx4vXqLpI6dFJI6ZPqcEE0tQFN970p2WlWwsFH yj4m/JoGkmmMRoLZShm+guJ2Og2/B63Ow/4xggZeWOYiTxg4yEZn6DJaE2Pd+E0sJN1yqDPY b1Ofq+hiIRlPNLlIDSPkqgcZH7RPsWp/Fjw34vO2Q+9K7Omz8kK+YfodD7xfvXbs9NkuaCjl m2ZJeur36olDofqPFmHqabXuT/swA08cC9S2qSOOyFmJoSK16CsHKxKIUYi4STvoHdT30qmN +m6U9SF99RNaIdR2Njs/eENeG1gQ9G7Nk/G3FbAIUGNcioRc9QCjg1oB+nX3meS8x+Wy/jac 0kYy1EhFnB+fqtRZdSzydT/5gKTP24faIcoHLby0kvKYnAyxbvx2LgqRFdRGPjYuj5UwsJRK IJpcorj4qmYG8ygq7Ny/YY+Gq1xGp8uTNRquLs2H1qGOafBuFLGQjP45eGHWAi2yR2DndkVn xQL6KdSQ4beud6me0tnep4y0T4jZq1PaWW1/5zf/ScZif7e/nykqduKoXaZ2FtGESDQpylJ1 U92loSSWWu/yDAydHvV+WG2YidytYyvphLdve0LZvXjxs21RgLCD8kG9RNNLXb69Y2tK2OL3 uFYz2oZbzUW5sNSQNozlV4ywdieNPZUzqz1BELeyHD7xwv5WoxmxUCHWl/uAiFhmHsVw9WYt sulp8BQ1q9LidNDwI6vaSlNilpizLZ84QpbRu/XnN4ySn/ebu3oYSd7gPN18Wr1XjVK8uS38 1cj1kh8v6H5k31FlAmTCo3U2yzhr4LLJwWbXbyLv94SMU+8kS3MhD2OP6pkLmgRpMznQRkv5 OPI7FXv2jTOODBYE/a4HnlTe99//3r7zlKluY0/wHzzXP/rQojyM76zQmZA83RKiCZGok5Mq YSpxSMVMpeyW1yCInhhyb79oEKy409RVKuyq089vyJ7PXg879eKcBIwkTnvfMKt/ETI8jQNB 79e/aKFVDpmjECn5tL4YE4mqYc58dm7w2KpPftiCzEIIWH5Ox0hA3UWZcXAKk2QD3c9pR9p0 D1O/LkdQ05Uylqp8jpGqTLeyLDmMyzlzF3jJC9z4Ag4EQ4beuP5cY1J+ST/FfCfCVsolgRxp SiRadj3zZ7PPNOI5flNEUviMDA9M3UbYd1UXFmdDOlP4bWyF3EPVWBoZYM+n5aLX0R88CeLA ucDhV471ROPrRFVPFU4LM+FQWnC1w93n/lNrGRmauM+tKrVd1kIgmMFuuCBRPcyP04VgNzCB BkHc3FDgq1azUiw/10lOm2D58rtOb6ewSwvo5x12pT6Cetr7pFxVK1oc+2aCF0AcOOL7+Ia6 lcpBTSf5RLJHcJnhhUhBVblT+sFKl+8wbpp5twHaAUan3BJ1gcsmRKIJsUA7LUBIQ1sgtdPx 9SQOBHGzY2Gvb1lW3TQh4sRNdI9y64kTiQa0duYn6LqKfaeVZtD2BjfR4/+YaFDifHS7GK93 JONka4Q6nfcOkSy+Hw/OjIGfLO4vh4MTng86rKqIiIwIMd1jh1zydHLIRd60rGzx6JsJo+4o h8xOOl/y5UbaSwTEMl2D+AgJVySvXoxN3yj9r7KF6aCOJE6ELp+NN7mZhkSipLM+l7KuTGAJ 3erjdatmutdxESOVQoIRkWhSkCjjb3lYTm7XngMctiGa1+55vZ3CLS2E9t63bK42IaaI4+w5 jhmp5JcakauuarK724ObI2+azAYMvbK5SVAw5zxkF6KY0+X+dBC3vBg2/ty2nSBma8Uvq69Y UeX0cib0U/f5FjHgK4M05DlHF+kwWn/jxHysj/Kc3bVv42HbHKPKFwEDs3/oxsKOv724P3Ol 5oaGpPgRiqnatkMbT/khs59lksC8yy1B5gK7du2ivLVLcLdYYnDdpK+bocQZtp5s+zZu0UOk 3I0jgQAJLGro9dbj5DzMNpJz5xEXu+qxjHXJNEX13d56nKcOUUrbvPvUEYvG0KvjZOEsv7rO VOTEkV2wjVtgGw/L7De4mdk4C5DaPJzMzlAbsF8j0zaLnk4a46ovwcXUwl3iXmoRr9bRNuBa mbWB8n6W/u4S2iOehK6fop91JYv79qWWqBQfKwWGYBEupQQfEljMWGbHGADEKwkL7GIqVknK 7VooawPG8qpqTIWPHd5FC9u9ccs56YAOajKKeYD0yMVAiXc/u3nZfngjZ4Bt7otMalEm548y FEU38j0m6WN+ASykbCo8xMUHCG2BbWFr08dtLeHZwdjI9MLrSBkYDEaP2byX64hlS9hVpocn gPJSKz2lffSiuM+aRuihU9U4YNu2wQ5o5tjnrO0kO0B6l3UdL3/g0J4tTIMjE3QLw5Kpo+wC ykKecVLOqPo4XsdL7T+4h+q+W1j7FoU4znGQ7fLm2n3Sw6FhkuXEcXK4i6LwcXqYSKhZ/K+M ATG4UA0h1tK2HzorHDIS86FcIqt5EeTtJH6EYejMCz2IINAxAgCxikL8O6l+jxu3GOjhH1IM Zlv6gVi7czwclE/t5NioUIQGmAc5K9LCN1vCLMlaBrZ9O638M3s4PB1XnSgPcdIW4WTpjii3 eoof64nyDzMHkB466chx74ftP2+lEtmliq1YAAAgAElEQVRXGGknwH2SYl66j+eodTuOOMn6 qdIyTzM5pqp3ixyQSQttnl11Iv7j5AI1viZnt8OoPpnH4Ef0CPkFOAVBvp1bxHg0Uv0o2zO1 do4x6vpRgdfSpfbs302tGnZYSCR0IpZ+apgs7oeZB6Q6R/ue2wLbTLsvCSNVk0G6c/KNziRv 7Z927GJZEpRgEVt6cGmpu6kse5/MLbCTWqlW+Yw9+iU0ypux3o1bDu88oaudN81y7jsJ4yAn dIxe1HE7LbdwG3eTw1v2bNoiKBvyc/jqBzU+MpLV3sb822gjuQUGOyIsEjYVX0uNaR8CyqLl BHh2ru7IHtFDchnhrfPrmEGABAKkWYD0wEFb+sw+epl8jh2+l2n1RtHqhR0RFg2fjq8FAUKx mwltYHkErcu86Htsz/3dbUWPMDXygKidegrI6p766TS9A2Ks+biodwnYyY2nQ5wIb5meNbla YKolv5deqaq8X55tYozySdjmrTA+p06/KyBAepN+KVnqp927Vg/jFnE+Hbw/0wbbSNY1ogHf ngM7KIthF4emTmGnhhhTzn3KDJZWoIz4GTxjYRv3cG+El4ZdHlzVne7oxBilk7DNW6mDI+ag kcKS3P+Tqb+fFOvOAdu1jVLvkd2ntHUKSXqKElz7YD/xGYn4Py3uXAZIDY7mupz0zvIKIgGL sFJzKdjmrbCDOgTXAuZ2VlT7uBgd2gL7kRIvwa+byTQ49feTYt1Pbt9JrZf3AI+7a8ddEw2J 03thB8ScNFMpj0REhvioCLCO9k/HJUSx8wl1bHqUQ7jhacC3edtP1ItLlcOidnWWniAbRUEO xjJ5hWwvejM+L1JS6Gwozf7aF4+2TX3OUmBKZomZJGzTVnrY1kOCx+x+jrk5DUBpeT7IX0bc n/ED78tZiPx0dLUn25HDwmZa90HcNIgDQdzQz8aXXHaztYLk1JdnkCDXQp20uyZDmXzC2HKt ogJhddiPMNg+l0vuP7M+uP9RAnueGISf38C5l6GFP30P01AqaPACQa+X95RMYBuond16WoQP +wuudwYH/m52JZyLj96pn/j596mr76IXws8pG0w5aPb7DflwvX30z1L/2V5Zdsox2y91hHl8 pEU889gnD/kAK8vY2sBDGnysRaEKVhU17bt8T85ECHaE2qmdu/gSHlimYHl1T204JnDU/DKO 4TgqbmU5/LdsXlOprZQyd3wP01AuaUaxFjvk+Ag4LwTbsJdW+74dO0XlL//mNwziQDDg3UO9 UKENp/ZSBkcRYw2CWBC0zHbhkIRtgME2/LTjBz5Xo+v31nLolaSZ63yIvd0obIO0h27hXRwI 4sCVcPCpZrjJoVMsMUePiFtr/8L4tMEaWV4Mq/U/qMrLVKyMpx6lXhrPLW9HnWSM2XfmkFiE CznHyyDJkOBIWzlHED46N353uYPZJ3DyRxgnt3WM+a1nDmXGG7gPb+A0Uoyp8qEd5MdHCDlJ MFQtI+pXxOiw6lCdKaT6nsFZFYx7Vq0ZpbqBpZESkS4vBlbvw3l3ATKODL0W0JUIbWCJCVmc c8g03CN+mHlwvPSL7jFHPrPojGQcnD1CKiIXZvUdRXbwwDYI6EqENa51UkKf4s8Yip/SC9Bt BHFLC6HVvvtVeI6Qf6V14XaZtAPPewbnNI9tvMVz5mKn3jrfDtl39uRGSszxffutjZ++I5/c DXh7XzdEcMPJPRtgsA0wAS7VcCQIhoOgRYbdCXHYBhhsw47dP/J7mFQ+CFrrGhv81Y5gtIHr EL15O3b/yO9pSitqeQHza8YZfbEtqzuyn+ewdLTL6yHKhtnUG6dO9F6+ExtXRx5TOGdXyGwD O+U93Smtx7ftMC1s148wbbVLHTR35XAQdL8azKXNsXoMN+3Zf9jzOuoh9U6yNI/5NeOMnihr I48pnHMoWmU/uxIGLhpF6e7l+Mf3h0UEoh/ghufWNmhsGXhiW2y44fRB6uDwHpGJcXlDyfXv 8aRN3hC24SC5VYqCDkWe4FIo+Kt6oM5+DtgGGGzDrv1btNM8O9+SS0PPTdml6+4SYV7ecr5G pb+svW0LGLBSDAnfyTqM585oRiBZg5dCwV/VAnX2n2QKPmoYot9MD0N1FEnYslne38Nge0wT LOt7VjcDPTthm4bYKXKIpSgmXl+W9NeEMZUpyK0daUOPGbDryjsnCNuwe/VlxcXrmGL1Yi0j 8wok4OancZWekkkXhD185ZSZKj6gHWkCgpR8K/3tDnm2e2Ew8uLeBnc6X/IifGbcLVWbU4R8 8Rz48bCCWFW3G/VRlNDJEXPPs0e5KAX+sO/wHlSV1ZOx1e3wf9iEMIDBDlAiYeI6gkSQvk3R 9yCowGAPx4H33E1gG/Yc3KCDN7n9DvfrdetQJfYx8v6ywAMcCK5N3F/EgE9U/bRYFgO5u7uP KipV9wSx2GZ0JPFZizBFHlc670LwWlV4OAi6XfI5pX6SHqkQYHrhIUuY+y/1svqwDfvJMUI8 ujGGE0MIN57tXLAdSi7qpS9xcxOBN912yXGx6fQpCS4HIm6IfOKh36YjW+AcdeWcN5WPacUt Tgc9TubQPL+ZPPCHTghl/h7I+kDAh+lQibPaT6/0DL8rXr28XlYf9sN+2B6LNGRj7/pvKe/h by/ur1TVzFwpuPWQ7jlZPVbQvlBKAks754ob+/A0b8/KPnztRPHt5aLmoZzq93iyVQzltVFc 9cpuLxU19GZVsQ3rzagaLbi9vJYDvHTIJWdSS86o7M1snKUmCVkuuz2bX9ubWcliijtX2DSc RW0Avn6yoJ2efai4ibVH+NrR3NY1JuQhc2u6oGEQz9Jf6tDRE/vSxP3kF0WNAwzB/Vl1E0Us KYC7loHOidyaPuZiB3KaZopZG7Bcems2v6Yns5Ixsi+nZY6aBHwFIC0UNgxkVbKdl5706rGC jsXS9xZFM/Idoxr5ggBpoaRtLLuiO4NNgd3p1cM5zYyHJcHSjpmCWqbgjMrezMY5epoX9iPZ m90wntcymVvdnVHRja+fKmz/VGsBKkultyZzK3uYh7Evp2W+mCVhRec066TUjxXemsyp7MFT 3XfLbi8W1fdkvmd546tGC1ctb0LraG5ND4OBIdlAmB5Q0jqeV7PKn7OqL7tluWRteasXi5tH cuht68tunCq8RV9I1MHvSa8YyqMZzHYtAW0j2dW91EXbm143VdzJPMjt4wXNUzmNE8wz2Iuv ZtPf4qbBbNYbRX9W/STr8v4IKwBpobB+IKuyG18znNu6VNZKb2RGZV9m4xybvNWsM9idXtmP r50svr2ylqqpK7Zztqihj97fqoHMhumyjvHcmr4Mph6Rxf2iqFuTWQzLbNUM0sT9uvhWpgsH XzOS20a7rEDg1hyzuzLzPYoxuHO6sGGAbVh6RXdm/WRBB2OPFopbR7OZL/yMqqG8jmWWzC2E lpEcxhVbNZLXNF7QPIx/34Wz1pGs6M6o6s9uZai3awnonMip6WNzM6nsx9dNFnetZwZZFhKt TIqB8Kp66a3qYBzYvuzGaQbTjsUipquM/MUxksc4g2vl9hLQOpxFuwYretOrxwspN2Ta2p7K rx9guIkN5jZPFbRN5FZ1Z9B7tFjaOZnD/p68+hpcLr01k1/dTf2u78FXv8vruGMhy0bcL+2c YZnB9Mre9Lpp1hsFCQRISyVtE7lVn2lwbs8T2kYz6T3qwVcP5nXM59X1Z1V2Z9QMZbcslHWt AKTZwsahLHrz+rIbpwtap/Nru9MruvH104UdzO28NVvUNIRnHJwG5sFhrbcPXz1a2DWfX9+f VdmNrx3Ja6f0qKRlLJfN3bs/u3WFbUKk0g7mkawazGycLWPIlkOmuHGA+S7KsghBoGPqvdd+ 7cTqvIKEdspoMH7FZDZRLKAhcf8D/GXE/ZVwcD54uN+vh42rnn//cMg81a9yaR4zPerH1gqy dyh4fCZ8PbXPBo8OMpTZFzQ+EzI1RTYh9B+dDptfWmuZ4UsLmPF+395VJqJTs+EgGL44jx7u 9qV2lsGcdhEzMx7I4Azp19fnP8jUtoCBMYqmtjgTPD7kz2JsC4LYlZWwqWH//h5Wn8zRtfsx rqxgZ8f8B/s+oajl8BWmGfTr7g6cWAidHA8c6vXt6QsYnmEy8l1ZwS5MBQ73+zEODovDKgji wKWwhemgfmaDx+7+4JkFssti+NJCCH2c+wIGxkNBEAuCoVOjAbRP9Y1iZubXsjDmQ6ZG/Nnb jXb7DoyGTJEPDq9gwYWQ8WF/1lnu8e8fDlkAcSvrvRzYDju9XhqMhslUA8P+8TCygeHSPGZ6 hDa8/kNjITOLYfPj/n29vt29gcMTmPmF0Olh394e394h9MRsOE3c73gTNNLP7LDKNN2hs8z+ nKx2rMxrY3E2ZGKQ1WWR1kiWq4bFmrhvKHic9fwjdmUldHKIdXmzGxzM3Djj4Pj3DwZNr4SM 9Pv1kUteo7C7soJdmAwc6g8YGguZo8+RP/nX93WBueOBIxOYReZil2mTQh2cnmHMAmVwwhfn Q8b7aMs7cJCyvDGTI0zLe3Zh9WB+hKWF0Okh317mYWQsitpfNh3p6fMfmKDP4PJi2NwYQxcY I1fbwC6HL88FD/Ux3+qZrn0sCIbNjAUOsiuwu8d/dCZ8YRn34Uayt59dCgV/VfZUgB07cwoR 7zixwHjbXD9LC6FTDCPJPDhhC3PBQ9RbPaVVK1hwAT02RL1v9PgOTYZRThmD2JXl0MkhP9bl PYaZXpUR6+OsYMHZoJGBVV+XlIW0KpixVRQChsaZlvfc1PuWt//wBGaWzRclrUcsRTGxOBM8 Nuj3oUYuhc5PBfWxqde3uzdwZDJ08QPjsIpXIAG3soybHQ2emA4aHQtmup31+Q+OY0CQsriX 5kIZvgz8BkaCphexK8thk4MBlEnq8e0ZCJpdCqPa/mKXlzGjfQH0cezxH50NXWDjYh++MBcy 1E3/yuwfCpoB6fbBSwvYqSF/lkuU+WLwHZrEzC/hFmZCxwfZxwyMBU8v4NYq7pMXw+Cqr7Zu isvx7BKWxT98biJwmPky7BkMGp1e/bWLBcGw6bEAxqub3fIOW5ilXzjdfYFDE5jlpZDRPr/e br/BUfT0Im5lOXxm1G+A3V2itz9wZAa3tExZOXNT9L+p+oeDJ+ZwK8vYhcmAQUqD/Xp6gyYX w5fWdHHNoSeGGf5I6A0cnUTPUNrsPzwZOrfmPxo/yt9e3AdrasCaK88G1ilGQKwPmrj/wWT3 EBAQfx3I4j4h5iN5h2jiPmO+fgiIPw0tfUCmr9B5K1Xf6sjWL18dxJ8GSNz/AH8ZcR8CAuKb wpKCHwLib8byPOZNIbc27z5RE4Wc15/k/wnxt+QVSPj2jfi6rE3ch/gzAon7EJ+bvJtPwoNQ +vJnDp7V5lH2RDgkGwe3JbXOrzqGDwEB8VegYwIALtl72/ILyJ3g1JZDhmojk9wLf09tWRXZ 8CY7J0vfXvfkUSkeMXM4EmfoXuRPnM/t+AKtgoD4NIobB2Iiwiyc0AgkGoFEIyz9ERpWcg4E j5I3uV++dog/D5C4/wEgcR8CAuJj+Px22zjFUUDz5AYJo/M2KJkIvAGLCy4ExF+c0IUZz3K7 XbJSfMhE6+dfvDqIPy+QuA/xFwQS9yE+N1mX2lGWcEFxOI8wnEcYziNlLcLooAsBAfHXonUY yIpU19KnXNHCqjzCVoZ0B10Gqh+mR/kJSqhQI7WFlANsaA66EBDfgsKaN2gHdWk56leSuB6P eo7/lf68b90wiK8MJO5/AEjch4CA+BhuXUQlFPw4nIqO83rtKyAg/qRgFmZdrwTw+kXrA13Q xtX/aSBxH+IvCCTuQ0BAQEBAQEBA/K2BxP0PAIn7EBAQEBAQEBBkIHEf4i8IJO5DQEBAQEBA QED8rYHE/Q8AifsQEBAQEBAQEGQgcR/iLwgk7kNAQEBAQEBAQPytgcT9DwCJ+xAQEBAQEBAQ ZCBxH+IvyFcU96v7Xl3rfv5NuPhg6pv/VwkBAQEBAQEBAfFNuPRo/BP/aKyY6vzmajsk7kNA QEBAQEBAfBNGwPRmsPX/FO1g4ywY981HHuIP8BXF/Wv3v/2/dhAQEBAQEBAQEBDvg9j/5Jur 7ZC4DwEBAQEBAQEBAQHxaUDiPgQEBAQEBAQEBAQJBCBx/yM/kLgPAQEBAQEBAQEB8acCEvch ICAgICAgICAgSCAAifsf+YHEfQgICAgICAgICIg/FZC4DwEBAQEBAQEBAUECAUjc/8gPJO5D QEBAQEBAQEBA/KmAxH0ICAiIPxPJ6fnO2EtuOW++eUu+HpV3YxJLjb1uRLQvFHyOAgmto3h8 BjKI6Ff8Jveb9w4CAuIvBSTuf/AHEvchICAgICAgICAg/lRA4j4ExAdoeZtU0uofV+2Xej+l Y6Hom7cH4kMsA6Tx1JKWkCSifxYpqgok3P7mTVoPAZYSPOK6gs4t37wlX4+iXGeE2o97bZGN 05mfo8Di2peR1twHuawUA5qTv1IvxrJvPgiNI3rHEVFxRL/cR7EV099+YP8yzBe39MTjbwQk EIOLXyTXf5Facq8/iM4kouLoBGTfja4GS7u+efc/Hy2D+VfaveOJqNS7sTdGCr95e/6aQOL+ B38gcR8CAgICAgICAgLiTwUk7n8dupaBtrG8lpnCjqWvX3tJ81hBy3TRra9T3RKhfSqvphdf 1YuvHs1rnSMwvFvaPlXQ0I+v7MVX9mY3TeU1juVW95J/xVf2ZjVMFnQsld6ayq3uy6S82Iev Hs5vX6aqtKvfHcxvHc+un8gnV9S1DLSN5dT208pcxUh++wLh07tTXmqlp7jn+6Nbdlpa1Y5n fJPF8/lZKGmfzqubKrm9UvbtG/MZmQNID510Fbh2fPfTGW3pGLCgYx2FLBHaZwrqxopuL5d+ o46gHTVFlG2kUJ3vjemcKW6dyGlZKOta+dZj/pkoLfU0M917GuXUNJP1OQosrnsT4yJ9WtRd M7Qz9Sv14n5olPe5LbDNW2Dff/evrULuStiXX20Ay24tFjUMFrQtlHy2Da3F4ubJgqapYhL4 Ve4SI1nXiIb8+/Zu/tchlQSTnC9QRfsEGuUoxfnj91tgG6kcEHNQTwFLvtKX42dhobhtOq9+ qqTrPXdvYkucl8aWbZv+udtMDd2W8lXbtgKQFgobBrOrV3/z9mfWjhd1rVBuqrcXCG1jWVWM AX34ypGCjkWWb+eS1vG82vd9m/fia8fyWuaZ2nBrjtAyjKeVXDOc1TRT1jWT3zBZ2DZfSlou vTWTX9ubSQ6oHclpWSzrWiG0jubW9uEre/HV/fj6mZJby5C4/8EfSNyHgICAgICAgICA+FMB iftfh9ZhIMFF1fOqXXbf168d4+Zp7ZfrTvw61fUmZKZrcO6AwXZsOo5UC2YSF/B4vJU696at OzZt3cFrm6Vs6C51bAf5101bd5xQjzfL7c6+maVw+OheyouHdxzR1MwcSWoil8Dy7pEdB2U0 0eizilhDckWtQ0C8s/DZ07QymTm4aauhbvovcZ/enVvTBQ0PgsNSlc9Y2tf/bcT9h9j0fEWp VGzTTP63b8xnhCwtDQR52mtqrFvc74lLu2gk4+XW/HmOkK+D4qbB7LqRnOa598aUAQHBOCHf X/Pbv8Fm4Rehc7qocRhfPVp4e+Wz7KmU3V4saRrIqmXdX/ySzBe3jmZXdKdXdIc4a8oYob+m uJ9f+dpLU9o08V54zecq83mAR6KFDd6fBH6VAVwuvTWTX9ONcVbTdMn5IuI+PlxV1YZPLyOo ojutoju9oju9ohtfO5LXBpb9lU7u3wtJyFWGZ0V2LrE/lX9rjtD8IqMiVU4iyPxri/szAOmB vYYk1/7VX758h/gDXTsWc8iR9fcTY9w5ftq9nR5wdNNWU+PC50nMZUZifFXOsf0237Fp645N /M7wwDtMbSA2x3ppbdm+ixJwUuOU5WXC7cs6GnGOUXfSSMOZV68a8Ow+sHPHpq07dp41FQv4 jXB7JRGNlBY8vmnrjk37+DcpX8BdHYbE/Q/+QOI+BAQEBAQEBAQExJ8KSNz/OrQOApGm0g4E i7Ser197kI2ViVuyw9WvU91sfk0nJtyW8/uDsO0HuY1T7Mtob/WEBrgonPxx655Th7SL7DJf RJbcDQ4IQUgf/0k6VN+HEFjwNKF2prj1RUTSDV8fJ0lJrZPnPS2TWiNr5gs6QYD0Mj43CyGt p+BYahte7hVT7hWT74z2kDxzavsBc0Xv+iQSCLQMAJEmwgh/Gbs8r5hy15AsNb6NXCpBKp7l XjElTkFYkb1axul3otfWo3cxyUVavH8ncf8uJilVjC8S0zCd9+0b8/mJRKP0EesW999FJxRq 8SMdmqbw37oj76U4z9vb97TLw/y2xW/fGIhVJPgbwc0xX1Pcz7v5wkWGSzfqdkj15yrzKcou 3MAoFvWVxH0K8b56ep55X0LcTw+xUND3l/W/m/+VnkX4QnQFRiVLCcdjOxbf704xCpAIqrIY y68t7i8BpLHkgnp3pL6ktOxh9WT36KteMeVeMeVemDQ7G1d+sVDni+/SSSDQMVpw825Q3DVU TLmxtuJZfo6fzpsLbN8p5U8KuslUJtbPT09TSwpV7hlT7hUTLHdeje+stWZMuWdMuZe3rbA2 RsmzgxackJRuoad3XsnHOPqqa0y5V0y5o0+UjqY8nygP7IgdIrQjhTRf3PwyLj0ezs13Du6u ibsVXj5R1rVScK0LGxGsqqK1n8vZOPdNRvM8JO5/8AcS9yEgICAgICAgICD+VPwfE/dL26cy s3PtPLEIJBqBRCPsIhChXWGJhLC8W2img+196ZeqHJFoXXIYEm3sR/C6CBZ1UgOa3uXnFxk7 hiHcLngXdMYwBBsGX/cmDNOLqn4Qn5yFsEAhZM8cPKvNo+yBoJaJQGa74h8y/+/NWi/CIcko uDWpda6YGlPSOh4XE2PlgjYMvu6d9SCP3AwkGoGMMg++EVINFlPTMuTdfBKOQRvYocX5ec8I wQX00PSqUYBL1muWwSlpHY+LibZyocToOUU6FXS5+F4PZG3kR3mbfSNDbJO0mCDnaXUPSe/7 mSSwlAQC164gzSy5T/BLyImfDRzCVYAACcwFavzMhQ6Z16MvjzEVciXXxMRXWLswmiYtVdUE BHgc5UZ5AOPZ7eSwscK6BncD+eOnbJQYxH1J+zLL9B6ABBbUvHFX2ibjUuFaBgKkkdyKep1T elaZ6xf3Y0queQVG0obRNvVZLMs52abnSTmAGRKtQxtq10zTuF8L29cnwo4VNHR6OGONkGiE 90XX7NeEtvHMzCwbj3AEEm3sD6AugsXUhBJF1c8TEhIN7ENozdNzTnAqnMY300qbB0iPgjFp 5khbSUWl/TtlJc381ZmCZ8jBlKLsQhCBtSEXBgASCHRMARcuO/pEI5BofVSBfU5/cecyU712 IQhknH3inej6sYL6Dg8nrBESjXDOd0h8QJ79nJJyz8BIhGuWWczdousNngEJhuR6XRJp9TLw MiqVgEQyrFjnfIckSlEMYYsAqS8iJsvWiRwWikAmuRe89fReh7i/CJB6I2KybJzc5RQ1OHbx nTX3U6HWrusYa578Oq2e5Sj9UGLOVRdXeiON0BW+ZSPrvTuNZ15p9fZA69qgEUg0wpudoW7H BABctveOQmiqi4iIwgTt1S2DqLXHGXlej2ibZ9X76n7GRGcb04bR7bI7jhCYdtUxt7/k1vI6 2llU/Vt8QoK+HXWZOaSaYjpSOxaL6TGLAKk3IjrTxonh3fJ6/7AkBBKt6xRvnvI6nTqShNZR PB6PdA8nd+GDhrqj+XXt7o5hhpSO5JjH3i2+Ue/hF2+IjLLEVIfWgIQuECCBGSXVPv7U/rpf ZmOo2/A6O6dQ3w6DcL/sV3IrqvSmA/WCNQqp8gdG2dTrQK0XiUbYRiK8qnE3Rz5g/Ps5xf3y Or/QJPqFENTggS0OSbrsc5liKZFRXOXjh1Y3dBE89NMpWWtJYzRjcOilQcbSyMEM30HRlqHV YTWMSednCusfB/mGmdg7CZ+VPs0lL4xEa1Pj9b2LnfIGCLfoyaAILcP4jHRrygxSsEt/HV+7 zv5SxP20npwLRCs7jB5lHnMtE58yr9gFgNSLi8xAOjF2J9cj72kac4G51+5h0GhdG7SCKOcR bqnjMq60eKvoW2E3mBtQ/yoru0DXlnYXjTPxrmA+I89Qr2OaWVhn2q2lkqt1vphEBBKt65xo nvp7RiM1UUzbGFB2wdYrknFwTKPvRt2YWvvIzAKkhwGBSWZIpLgs/OBeBWmrIA3avLilOROW slroi5Yi7nvl+eIJprT+xtwOv8FaclFjfwwu1Jw+jKEIZLJnSU9ay1pbSCc1NsTE3IrX8xF9 ylq7M3KLNHhF1WMfhtYxBNd2OZtaSyvbKIZfsZeAndIvdcwdYiwK6xdibu1jeoG8RCutEe6K Kone5O2Zi2kIu0R1mrh/tcbZE61oHG6K6Ui/vVxCAgESWFjxKDo8UEvyxOajSLXQjhQSCJBm ANIdS2m4ukMx0+OM18vdXH1PiyViby0VQDn3P/IDifsQEBAQEBAQEBAQfyr+D4n7s/m1LyIT S62MEeLScB5hOI8wnFtE7YS8r6qsoKJljG4GNbLl92TCBXs3Z2FuOO95cqQ0v4KptGOVT/FA dvMCQAKB2qfZcX4iMud2HtMQ1nUxoAefOyluJo4sj6ykpvG91hgW4MYjJMtzYvfW/dx7OKXJ VfMIw3mE3fXCmhmE5qms8pte3oz1wnmEEQKyKENsM656lJxBpbhpEONmKC909KiQ/lltnJOZ /hlxZS5hOA+3GJ+ouVTAvbgWiu9r1qV2lCVcUBx+ZN/e3QdP7eeD06vWDNfBPWD6D7+hNz69 RF9dTlhcjkcYziMsxyshKWzufGqPviKyNHhtQ/02+0am2CYdI0c7CX1LXpVIryqw+DaYHemq rGZ9UsLVyUpcCL12cf/CBZSzxXsz/K0AACAASURBVHaRUH9gMq+NGtY5BVwrM3PId0i4jyd9 QXFf47SBYfoFEwdbeQUlHmE4j7A8jzAvn2asadRviXSpYjAtu8TBzJxhiuFc4oY8mpGuifeS 6yaL11YvCJAGcqvLjeW0hHm5dp8z5TXMi4gvsTTUEpOG8wiL8CoiJd2ep7UuEkgg0Ph7Qlq+ vpbSWVFa1bK8EnBhc8Ax41VK3Sz5EgBIrU4W9tLCIsc4Tm3eeOLoOXkuajsF5M21EyeS6kGA BBYQ74SjjAXPHt9yHm0U+RAggUDbKJAVraltwMN95qSQ5innB7mtlO2KAuKdcG8LQQnlI3u5 hbQDjeKvOYd4Swio8gvCOQV0xI1TUFVg8W0wIyXeBCF1mEcSJhrg5ewkB9fiEYbznBPlPnuO U++6Z/EwdcOGbIqbbWFmKci4YoWNJHSjkWn3k+k68kxxy9OIpFQ9DSNhepiSpGUaXFlLRnGt 4v4CQHrp7+aqJCt1guPMjh/37heU56QWyydjLBXwS1wlzR91ESB1x+eWWJnbSzDMNQ/cRcHl YmBp37p086HkwgsWqvCzInCeU0dgfBZsDHVbh4GsKHUtfR5urkOHDn9/QJRLSJFau4mIWopv yyxdyL49DzQ+jcTiENoGDMNoKS4hcV5F97TLw4K1p/TJu/EoFBenp6XER19mOoIKfkaRbRG1 49QUT/MA6YWfq4uSrMhRHsV9PCFumVdRnm5KqpqnhGW5xZROKhf4X+wnB5c09iWHOSsqa/AI ixw9dn7PXlsbtoa6bf34K5WeaJQ4vwq/IJxHGM4lYcSn7ufuY8F9lPfgEXlxqyyP6xSxOzE1 y1IPziMkw8N9dPMhS5XVhrrVD9KjUOfE+X46qi1u5Kbn5Hieh9wXgRMSVjIOFdFVYCk9c31f 9s3LBlLq5+ljqMYjbK/lSwwq7815z0B9HnG/cwaouIPxQcFVNU9Ra+eQdRcRPCetZCAXR9ls TkzJtNSDc52VOLD1h50nhI8KMCxI40KPvLeMZZKDGdaDkpCaq0ZAQyhxKZ9yAU7kVbY56qiL S4gf2nds166Th4Th3NR4Qe0g7Zg3DIrtUDbhpoWBuogUrUAFHmERIYNU85h1+gnH++rp2WKU XUsd7JD8osqUXovon1YL98h5RctVRWgbSi9MMtAyEGa8AHl1ZayS7PIfJzXTM+3gCXXu5nA+ EfjJwzu37TkGOy5Ji5dzLfe8QK+6qPq3hES8nYkeh4jSGXLMOfVz4o6a0TXo66M5lPGZA0jP fZ0cFWWEj3DDD/BjPHPKUR4uiioap4RlucVUTyoXBV0ZLCCBQMdYwdXmYBtTYRnV04yNVA/W D2mMLF/rLuAUQGqyM7KSFBY+cuLU1s0cx88rnvl/7N1nXFTX3j78+//cNeecxIhGg733DiK9 SpEOI0jvvfeOdJDeexs6s+m9DKBUAXeiyUk96cVg7wqiZp4XzMAMIILlKOHi830TZs1aa6+9 ZwzX7Fk/Vp/8ijaa6ePp5yYb3ybIMhUxSyUFUxUDI9bQ4vwng7RDL8a2Ty1O6bk/krPLNRXF BMXk2K8KKYtsu6yfXrqs8SzhPskobv0m0myfrN9Fr6qploW5Icqy5sLahSFdPyaFqO4Tc9MO Hsrsm2ow/3A/J8SUYp+mmXB1+nx6rhBZYYrG2TaZ32STDIT7CPcBAAAAAP5ylk64P/hzbEqM 9O4tq07k+pUy98Yp7bke56Z0ZMfKTTJBWpmMiT27i8uyjCiah0Q8jCsYhcxb9a8k5qRTeLZt O1XlU36ddWv8Q4KsOqV6YtfKgweFJhv3u9loCx1UEz0zntfHVutyHtvylPVf8nbzVVPxMJka l0G0fprpb7hhjYZK3HAkezHejGBDFZEVm2U+Fk8O6LxfQDIIotrLWGflWkOT5lvpnDUV57Mt Tzq1xvz4qq3GZ4Oq7xIkgyDvFLR3Ggnv3L5WQdK5NnRhq80K9xMrTT2tFSVVRULu5XTf8zJV kKQ4SlrlBJiLC79EuN92LsjbZPfGfXzOX5wuY5XLa7+a1/d0qoZk3w0iwUHRrc4m9yoxPdy/ Q23rMxSytstfyJ77JIMgf49NKVTaKskrvppbPtgo/hvW2W/QlxUSlA3VSro/UXOypKfJ1tRX XiHZh2RM5vjUqnN+ppLc+52NM79JG1zQuGyq8wzs3Pbwqsvs37NSviCAdoUgv4jIoJ6QTA0/ +7CAHCsuKHC0dd6k15I7tVH7nfzWdkOhHYfVkizSfynl6HAe2/Kcv0WUhkjoZlpMhPuTSgp9 vLzZw/1Jpy0MdZRFjkoprN6hQcm9m9zDyMpId/XwVU5mhezNrT6eBmvWHNjwoZ5+5hcJJIM4 93VGkvf+lfulvPoDWhgEyaANPyrr6TFX0z9pV8SRvNAID2O9tTttTJpuZQw9I0hG+eD36bQz ItybRKy7WWnRA4Js0DsuvOVv76068Aa35aEN3yk+m6MuJCCommJKnfp9TESwqpzkRvXi1I6x slepa5rmr2zoP0u4P3UW5rEtz8ANojRIbJ++nCPb6zc7UlNe4OPDpwS8v1lwuD9wL8TPTea4 9HaD1oL+ceYvmwaTPfU/XqGqnHAhavrXUz4Jik/i32wsL/HxBl5rSuhgGnk7r/Gc/jEL++Kv E6f3/0lQWITIBmub2cL90tp6d2uDndu1NPMfpPYwCJKRT7R7G/Ov2L1r5SZzjZnxPckgBq4T JYGi4j6asz5K3iVImrqc1M4Vhw5LBppXMUqHGQTZ7WisJnRU73j0k+LB51cq7r5MxJoe2qYq 6lQT9JxCrK8n3D/3GxGhtVvARSmwf7ImcHKIjazgzs2iNqopjBK295OX3Zbns+AwJ6G1e474 3Yltm/aJ1Au35Rkvre6IcDXhUqaFTH0/YJQg/2mncVzwhKdq+NcvUYw3wUdbU0l8636t9Yd9 HPvGckkGQTLScgkT+X0fiCf4lf5RMsQghsbyaoatZNfIeZ/3rWF7em2h0clTR4/76BeOlg1P P4MJPtonTMKUz/w0+9BDDxOjgk8qKG+WyzozueNN1+fJsZ57Vx6W8uwLaHrM+bWhCwHRifxb DBQkVq3nsdU8cyGdvJVT16XLa2pf/l0S+bS0dSg6zGv7kTC38t9y2Z4YYK0oIGsq5dZdNPhy e/3Pe1ueA3vX/U3wsFa2H/MLT9/5OhrKy5vKRo8xF2doNJNKOBor77b9JKZ58ssEdwiy5pQI n5BqinH2aNlLbWE0S7g/PF7Y+GmA7sETAZd8mP8r8owgH0W5nBRUcZP2JSfGVT8scVw/37Fm 6q0pKjjW2jHcsnq2cL+GauCao+1PTrT0NRBUtk4xLXjh9CbCfTlF0zSrQrbavEVUK0uXfQj3 5/WDcB8AAAAA4J2ydML9iqoAP6+95l0xDbeLWSk5bfhpac/1M576Wg6JWpkMghwnyK+cdQ3V DWPMi24XTP3t/bRs4HJGRQWFR0ojqJeVnjwkyKpTojw8Il6U+MnGY0XUXA9n572OX+X0jE+N Po9wPzXSxdg18VQi+7gMYuhx+dmfs9IDNTxbXNmL8WYEa0gqbRQ8bdNxjzr8jEYyiMGHyZm1 xtKSGrnXE7s5ep5nuG8pu/aYz+8RzRN/jT+jDY8W0P/Ibr2W1/1ogbecT4b7g2cK8pyMdD/i jwjMjZA4qiNtUeRU1PqS4f7QWEnPT0mlJSeP7tyyhllPb9UWXuGg6zFtrGddeEr038rveTQR XHKG+8/Kh8YK6LeKzo8vcAvp32NTYuV3rNukTbgX/s6KNZ8R5KOCzhpLA+8T8ikTaX6Is52R S4p1yb1itkCkfHC0uPWrzADDU+GfelQtaFw21XkGauJb96pJBY8ktj4oGXxKkOOlAw/yO+6X DD+jkX0uHgkU7fzAs6OlU5HWs/Kh0QL6H+6mQfZRdWEcHb6hcF/u2BHx/RrZgW3X8waelQ0z ygfuF/XcyZ+sV9nc6uNosGmVhGzkTzEd42UkgxgeL277KtDwqLxPv1sFgyAZpWd/j3OVVvZo cyx6UMSenA4+LG7sj4kLknC8EFN/nyAZ1Mr2QAcFIfdvgmvGWPtlPSPIRwUdg05mmpKibzDc L6T/5Km5Udq20p56n32I0r67ccm5BvJHpMLvxL3K1uevMdwX9TjpczZp6pd3qZ1XMttv5PaM 0y48P7+eVXYUxcRfyLYp++zo1HOHxsravsz00TqolWqS/C/Op3wSFO50+MPtm7SrfYp+o/aN lTFfgzdnew3OFe7HhMaamzppZd/I6X828alJ+eAotZ70Nzq86YC54kuH+0f38UiFaCffKZx8 985JdXLyOuz2TdH553/yMfyQ6O81llFVtqa6NM7e5nWG+0qxejFfTC5XWe+tPPofWR238jnL wL5suP84u5Bw0hHdZHYhomHaXjEvDPc/C03MlJeI8mq5kzc4uVx/EuR4Ude1AM8MG7f0lyjG m+CjLSpKOaRdENR+p/ACs7py2cDDTFqP+XFuOe/zfjUMorE/OcRxh2FTUOWtYvZPTAcfFHSd 9YinyhvSS2ecwReE+7VFBvo+x/WowZ33Sy78yXwDHx4v6/ouO8Vd+HiwfsQFzg1/LgQE2x3m 2r1Jt96v+Hdq3+My8ln54GhB+82iwfEy8nJMYpHecUfzphvpg0/YPxUo6b4WE5Hi4J1qydpY aYHmH+7rqViV+p69z/r36ElxVbmjV9hR/Y7SiU3VWtq8gmMFtMszukbZbrF/RpCPqPQBR48c c6/GxNcV7nd9nhTtt+t9Je3sr+OYp+wOQdZq8B4/rp9nX/V4YlwPbX7Rk74n436b7Kq0915h 913WK5Qz3B98UNDzgNrL3ATJ14Ci61noXPfC6U2E+wd3rPrw71xstXm5lv99Fd9asaRwhPsv /kG4DwAAAADwTlky4X5qQrSFoY5A8N3c3uk7ZhQ2XUqu/TGxg0GQowTZqq/upeNYEzF9w9nx 4rPf+WkLKPt0uTEj2ocEWXVKwU7dsiKIfX/hstLT3h677D5faLgf5nRSUmD/2gNKPKKchE/w 8Oxac8RVPXBoKm3MCNYz9RO0785k24U8nUq3kRelZF1LOMfR83zC/eKu7+LTIlRkKAKT40rp 8Fg0R9TcmONZzzEZ7pMx5z4LDw8X3CGuqC2+TtBd/fRAMkF/yXCfZBDkeGn/lcTsZv+EiYK6 pU6h4YrHKQIG1JklBIjp4f5L+z02JUVlH69ExE8x9HHOh64HeUXoarqZNowXDf3opClzbP+B zUdnnEEhWZ7d69bIJRolz9hFfZ6q8wzMPYS18qNaZ8uDWspMtCjb1hzZIzpjaFGlHRt38Gon WhLsT3lD4b62muFpndTfnluvsrnVx893t3h8eNPDye+mlHT+Gm3Np+DT70owCJJR1P6jN2Xd 3sPCW3lmHIug+MEjPFw80U5Fv+aTNxIz8g0kpOSTbydM3zvifpif00nVNxfu389vHjDgkdBN GA7vnv5oUWVHhIPybrvPwupfZk8SptcS7g8/Js59E+nnp6p6cv/UMhqr+7YFtb3MrDLCLDXt k9Xjb05/aPAm0ZIoq3TGOHiQc8U+CYqNFN5ra1Y0ktn7wpoTc4T7l1wt/dRUwxy7GaVscXZ5 7wg12fqokCvlpcN9KSsNhwaOHcCLcz29fA86f8Ee7hd1/h7sqClzYnINFXhExTau2nfMMM+p fvbDeX3b8pDODrayJ9hfCJ4GMYMzv3s033C/lh7g5cz+sjp0hG/nrj1rDPsj6u9xNn5RuN9B 93Yz3cq1d7ew4uEZbzu7dxw8IGWrWcgoXWB+neCjLaPpMbPsbVnHjxkuYiL2TQ6FtwvKG/0M j/5jk+huPvkZ73iiOw7IbDkc7DcwTp3R81zhfk7wKes4hZnldofuEeeatY87Gwa1RXI85UJA ZITIQUfzsmtZM94MCfLz4FBvfq7NW4QVD85YnAN7D+4RNRIP/fWl9u+ad7gv6m3kfy6B/feN 9W6no45oNZZOfBhTXmBvqLhsDd8RkZn/cEhs2y7Gqxzh0MRej2G+0uKCteQOLtsqMdWzAEVA 0okSff5M133mtHt/J7LtDx8xUfTsiGbtw5MdYnpc0U7EviN99n9EOMN9Tr4GmvrenN/3mt1E uC8pqeKq6lfHrPcbW+fh76uibroLd+7P6wfhPgAAAADAO2XJhPsx4QF6J5XEoxl5fXM0e0iQ VafUww3dO5JnPFrafTXGVkjJu8upnLOxRydH45cN9wOsFaTExfYq+FPMZuNI86T+MLXFc0aw kUu8dPD37D28SrhPkKMlPf8K9A03tGKOqGbie1zdStW22Kvwx+dtLf0cbOE+eTeNSpgI79y8 dec2baoN9Uo+8Srh/vS/0ou7vwj01T/K76jhdXZm1d/XF+6nqx0QV8u8NW1hCZIRFRxrZmSn W/64aPCSjYqskID80VPPOYO+bYHEjO2A56k6z8AxQc6u+7mPamrv3KsmbeavPtvQxhHdwRyR xxsK900M3DMd5rhxsrnVJ+TMfvXa/Km9g6aH+4VtP7icWH5IXI+fMtsaWoRRXFvCG28Wkr/H JKaqHZJSy7qdNCNhjwp6iYK6U6f7ReH+rbymDs3dpyzyLsXNfLShLzXAeKtZf0jN3Ze/5F5L uD+httM3JIFtDW3ldd3UnSq9qhacuib6G+i65ernzHzoLkHSKAphJtNj9E+CEtIk+GNDe0YL Xtz/HOE+3UbP44RsrAfJ4NhdauA6URr03Ph+PuG+fKjp6V6OR2eE+/kNnwf4+QhJURR1XVhr 6E0xsziyjU/U+A2H+ySDIBm5RRUuPuFTZ1DDRkE/QDu0PYxVQHjCvML9uk5fJ095FSNBtjcK JbVTwvyH1hotPNxvavRwMN20XkbC2Edltrcdfb9Kr6oF35ye4KMtbxI6SwR/7lciXFPIusY2 92puSY2b9uEPD5tIaXnO9mYbo+feGDn4tHBGz3OF+ynep5zSZ3v0EUF+ai5rbxzUwLk93YWA mFQp4YTw2UtAXwgI8ji6nI/P2EdxtsXR8iiyz786c++geZh3uC8TYhbUz/HP4rRwvzDTxkD1 g71aaiZ+sy3jGdOQ9lD6S4b7Oiqi3ALW6qaTPcfoezZHDU2VJi5u+ybWfP+GzQK7JM0UJgsO Kwhv2y6+WzXZa/Zx5w73ZTWcsm1e/G899txHuA8AAAAA8BezZML9hOgwfQ2lI95/5PTMsdP0 5J37tbPeue8/88791xfux3jqqZkEKEXP70751x/uT1fWeyMlwkJIyEDOqW7GasyNPdxnFDZe jPC2FJS01In7Z3QXY1q4X1h9NsRaar12Y0AF5x3B5Wm6hj6CupWprK8mUJt/SK34PKl7Wlr0 gCArNQQs1a2JoBkz+Tffue+ur61qmmBS9OAVxnqOucP9llpLMy8pSuppzlubn+/lw/1iarab i9ObC/eLO34O1tslYlVlS7333H5IBjFx5774rHfuPwjzc9J403fuH5HUSxgO75n+aHFVR4Sj yjtx5/7sLvm7msuIGxzzu1I4sLC7hjNCLTUdUp5z537S7Hfuv55w/6Krha+qyhu4c//F4f6d uHSqhojQXsvWyIbbrGajBHnRUl5VzerfEe5P19xqZ6AvIuOolnmvZGgqGp5PuJ8T7qymaCli VRvO9n2vvJI6TxPxDSYDC79zv8fPN/CYgK9721juc2oPvIS57tx3FRexa3IovF1Q2XraUX29 Sm1g9c35bxn3+u/cnyvc/1fYmdgTB3X06sYyXuZdaA6vL9yvLndy8tgpl58y+HThxd7nMmtB XQ7nb2eVNJ06tG6fgPge9mrDwgr79vAdkHZUSpr1k4+5wv1I95MqJtHasX/M+OrYOEH+Hpdz KbH+aj7JQLiPcB8AAAAA4C9nyYT72dlZpvqUVfL5sY13Sqb+4PyTIMeLz93I7byV1/OYIMcJ 8ktnXUN14wTLskdlHDunX82uqTzJIzl9z/2FhPtS5vmGyT9P3nxa2nMrn34tt4u1JW5evJaZ L59FQ/a50XK2P2tpw0/Lem7kdt6h9o1NhSwLC/dNdB3iLInHrN88Lu65ldt+fWqg4bGSvnu5 nfdLJ7bvn3BhjOgfMFfRVjHLcHrxV93ZcYT70x6dFu4TLRfSgkw+kkpwy/uFtXvynwQ5Whjv rWLgx+80MPnE6JBYEx1jStbNrN5nk/k+bfh+WU8BRcT+pH1N2IyxXl+4P7HnfoVX6RVW6vcn QY4WdtVaGnifOJHsTTJKSEZKuAPF1FfW79O83vHyCxxnsPjslZyue4X94y85h7nDffLHAE+/ k0p2mtk3s/qesX348YwgRwu7ruefvc8Zc18MSUoWPRzo2/Ygb6Lx0OPy3pvZbSO53az968/f IogIKa1E07CLxUPMV0rRuRuxEQG6urpvLtwneq8S8ba8lAjNkKH83sfsTy8fHCvpvp7Vcbfo /JNykpFf0R5oryDk8UNo/WPWTegTkxx2sTj1anvuUym8RmYtt9Mn3iiGx8sH7ua2jeScfThx 9gvpP3lqbJC2a3AuGWW/l7x84EFCWoGB/GHJ8Duxb3jPfU93j73WQ9l9zO28y88/Kuy6ktV2 q4C1nT1t+Enx2SvU3jGOTcnJJyXULFsr23XardS+BV6N2ZHqxv4i9m3UAbbd3ofHyzr+leun dUgr1Thpxp77ryfcn9hz30Ur527+IHMTdmLocVHTpdPGr7bn/ovD/U8C45LFj0YEnhujXmAd b//V3LYOAykFJcs3Gu4/Kx8aLey4XtA/zvkdi7HkmBB9AzNeT47CANTm752k96qH9p5unnhh ThQFuZbTcXvydeRnrKXrlmVfPfnKfVLSczslg2qnI7LeeNZwP1hL+4xT75OyC8z6qyU9t3La r+V0Py4dekaQl2OT0k8JKykm/BZDnz7Jou6b+Z23OS6V+WHuua9TFNL1YHLv+7LzjzKJXovj q+W8B3xrGETX5ylJIbt2u1hmfJHSx1nndvBh8blb2R13i1n79bP3POee+4X6+j7SBsVhvU/Y 3r2flPf8lJ/mIXI8aJY99+cK9xlpuWVWJ3n5PH6OaHhcwvHhx5OSntv5Xbfyep8suO4FySDI C6ejEiQFIgK6n1CZ795jZb03s9pGcnsmB5pfuE9eDA6Nktlja9J4LfX8E46PcIYeFp69ldd1 7+Wq/r4w3C9vH4oNtl/znpYh9V/TviWZkRR+SlNr48lq6uDT8ulPnCvcJ2qoBgZ+skYlIV0P StmrJvT/ktOWpnDETtuv8wzJQLiPcB8AAAAA4C9nyYT75QM/RCVESO/ette8i23HjHGC/MrZ QPWomJmY2wAzHCzNMjL2E9eviGe7YzGzpMVWZftO7UqfsuslzBRjweE+7wEtYbuaya/2h7rq SxwWPaiY6E0yikkGMXAvLMj/xHHxzbrN2edGJ59b2n013l2FV8JZJaBv6g/1hYX7ioLSOoIu 51m/6XdzMDmyQ26zbnNO9xhBMoi2nqDgCB6JlJCuB1MxXN9NIsGGT9RWxq0tfmE3Zi4k3B+6 nldXoXZoo5Q93bNycmGbDKT4jskEa6ROpcDRIf7Khz9avoVCyb6VzNqJpfTcSJybtLB+hkny zzPvPXx94X6h0lYJXvGP9xrn2OVdZU2y0UBORFA2VCuRWUG3rO9TD0czcWE1fq+v2bPvoo5f vbT27lcONU745iXn8IJw/0lJTb2HjdGOrRoaObdTpm4nf0CQjfoykuLqiaZU9vYXQ6Jc+Fbu EQ66GTORQTdfSPPTWrd+A4/NOc+JL6ZcuE8MlqkLqcnq5bs1MAjyMUF+6aireHjdB8t3SL/B cP/CU6L/lrupwjFZMynPQfanUys7/cxkuHmDbQt/yiEZ5YPfp9NihNdIqZ6+EEqfaPOYIL90 1JY98PF7qw+8SrgfJb97y3bL/vD6+wTJIM5+lZHidWj9pl0aBQ7UawTJoA3fKe7KUhd2POXW HM723KyMNCN9nY3qRSkdYwvd9IbDPMJ9J52TXNtd7c8+yCEZBMlIp9ZayGxb/bG+Ts5XiRMX f/uPnho7lH17vavZn/vDaTdzBRlt8TOjRecXGCwO3A3xczulbaKSwpj6wODsl2mJAQc/olAS LkRO/+zqtYX7pbV17tZ2+/Z5O3Y/mjheoul8kp/2qr17Vm4y13ij4X6Yr+BaZQ3qw9SJby+d /SI10f3A2jUf/u+WQ3pvNNy/ldvQrn9MSif6Ujid/ffd9kamkqIuOsXjnHfuf+0k/f4m2VDW Ryz3CLJOR0JkB6+dnO+FiTZ+xuKSmh5qMb+ynvW9v5uN6BauZau3chvMui2Pgbig6jHfb4uZ 9Vfpvq5Gu7by77Iejmp8QJBPS1sHowOttn0kqhByKaKDY5IOZjriYnbqqYySBd7Un+Cjrako vpXfcot8dkT/+MQuLmm5hInC/mXi8b4ll4sHGcTweGHzZwEGR3cJumhEDHNk7mWlzobGm4/4 Og+M587oea5wf/BBQmSwvrGtkN+3bB///5JekXF8FY+cZ19A02PObzC8INwvG/g6IT+An2u9 qMMFP46vzX3v52otK6Mv6s8+0PxdOB1oy7eGT+TM48SJchENffEeGitXr+VzmhxonuH+45KK llBzygerjfUKv+P435jaQkN1PSGFMKvql9yWZ+5wP6+kxtVI6r8FMwMrrk77Xkh5bZWjqdWu 3R7O55/M2A9wznB/8EFBVpq5vuU2xZyooWfM/X+6PkuKddmzmuuIcYd7+cRnsQj3Ee4DAAAA APzFLJlwnyBHC+jfn4kv0VGXF5E4waoap8gjKiaoHa8dMhxWfZ3ZsvfXlKRMM22tPaJKRybr y0kbCxlleBb9wYzsO77NTfATlRFcw717/TZZEaM0lwZG8RAjJiJYW+7Iju1b/7FV7qBypkf5 b8y/ToceE62fupsbiUmI75ysdCpmqWiZF0j9NnNq55mvw6OSdE4qHROfKm13RIyy54SPUVBn dP31IpJR0n091NXghNDOX5aBVQAAIABJREFU9Vv2fnRAT9SoMurcoyLy88CQcNlDAptWreA+ KMtv2+BVNrV7Rm5VjaWZId9BQVafgrxKLiecu31L/yiZ+CO/he7varh22e5dAvKHpkrqqfGI 2Kj7twbWXy+a/zp3XoyKCRA7dnDlf69Zt090zwlvNe+zE1vrZKanGBvqHOIV2LFxBddOud2n 8p1yfibI8dL+3xOz0/Q0DUXYyvpJmqZapX6byBYYRYdE6qsI8tt4iRxT4xPkWByLhIspHaNs 0/g8MDhMUVTpsMDxrav/56Mtx7bwKPEoukh4nF/w3cqtHe5uDsf2H9+0VvdUKk3TxEBKSmb6 JKcKcj7Irr3odzpGVU6cT0xxqjihhAaPRqRpzIXEloXtw17Y+GmEt7mQlArP0UPrtuz7aLPQ ZJ8ixhkWWSNTjfuvZte0eQR7SQpMLQ77JJPYq4aSd/KqG72tKLv3Kx/gV+IRVeLhU+bj1ZMP JzwqrmYyPzh5QpCXE3wcFaXlNh9lFhEV1EnUNXJSlxV4f5v8IZVs74rL+eQP8blZJ0WV+ESV dmxcv24rez1hD73I/ljWoJlpiUanjm/fuft9bpFDQgG2pT+mkTdSi6tMFY8f2Pzhqu3CWxWi dFhbAOVU9nv7+KmqcBzIIUkDnpNRTomXUjoflJAMgnxY0vvVmaQwVXkdfv6pSqeCOknSshT+ vWtWHtY7bNEWVX9rgW8Uj6jt/UERtke2Sxw+eoJHVIlH8MRRQRUxB8I+56fUztHJxYmPjNHW 1OOok3ncSsqS6l828hJ1MpPT8y10WV3t37F6/Y7lU6fbQz9qgGN//3O/JsSlaUod2y7KLNe5 X1Rnv/xppzN98fS7E0l6Qet3zrLv7zogsJWXfRklBSh+mkFkdBujfOEfP1Abu/0CvKRFlHgn OxRQ5xezUz/TG84al+i7QeREq2vo8YiK7ty3f8XyvbuEFJgFV5Xcpb2HigZYHwu1f5kR4y8o pTpRB3Xnrt1c723aJCg/cUTiBjFmBaxouP9KVnGdq43VMXEV1oFoCcrY6nkZ7+VzZY/vM1Li DPS1eUSVeIRleY7s5Fqxfc0Oof0T72ailgbJ38aeZRDtX2TEeAlI8nGv2rVhh7yERa57I6Ns mBEV7KMhfWjbtu0fbFc6rJbrWzWST97OrWzystI/yKt8WIhZF5Rf3Ew9MkaMZ9+O7YcOasaY FzBKhxgE+XtEZKyWInNZ9m1ft2r9ztW7pZizVY61Svty5ocWc7qZU1utsXPljv0iO/k5Xghi OtHGsV8kd3OkrmX9NzOKklRk5I7ySvCIKvGInuAR5eE9maQd/MmZWua/BTkVNEszE6FjUlMX w8mAE9q+aqKb/r5RZLcW1aPgN7YJ3M+qptnaGu7fIs4jrMQjqsRzTIZfzkrel+5Lu8n8bO/8 ncKWwYD4YCU5bf5pk9QNM4j6JKZt/tHwvfzWPgctisCetYcUPBRtC6wNdPaJKTOvHFlzUdMc 17yfc1mfC5YPPKBWng1wd1VQYa8XrcQjYiilG2+V8Xnq8LMSkkGQ15Pzy0xUlY6KKu3bvnbV +l0f7z7OamxCCehi38WouO3b0Ig4FTlxXrYOj8kayTq1na66nTfAIEgG0XuNyI5UoejwiIru 2LN/Jde+XZP1hJU95XwvlA5OvvYfFHV/ERGfqKmiJ8xRsVZC4GSARsBgWN298pfZc/92DlHt bk7ZtlvpoIASj6gSz1FlfgEjhega78qbWT0Mou2z1ChPPnHejz/atWGngqRVgUcjo/wCIyMp SpcisXXHnmVrxI+IhDhU/JZBMoje6wVEm6ero+SJkxwFdXm1ZSxTbKhfJvcs6M79MYL8wdvB Tpp35/r1GyYL6oqaU21zJ+vN/BYeHqkuxrtlLdd/rDi8i1f2hGujZxWDIO8TZLeNvoXUMb6t Gzb94++bNwkrKoZ9E9HMIFovpUT6HhVT5hHl37hm66rV+7aJKvGIKqlOPMo+gbM/p6XnWxno 7BFVYp4UATk+kZPizjWeZbeyexhE93cZ2QmyYuJbVq76ePOR3aqhp+J/LR/+MyMpUpcisXXL 9g9WHN4tYqmf/mPWjwj35/hBuA8AAAAA8E5ZQuE+gyAZpX1342KizBw4CsdZJH8T08bZsu3z +ORM9janXHOtsq8UDbC2QTj3WwG1UNcmiGLmTzGLMPKvD2pjlAwzUrKKHN0mKn+GUFyaQuuu sd+ymlda5+4XwVZhtTWAdmXaDIvpPyQmxOtYB0w1swynBA1N5sKlfXfioiNN7f0pZv4U6wRd /56k3rES8sfo9FKLyUqGEefD69hvw7yRnF/r6MhWYTX8bBD7Pafd3yfnlhua+Z/kKF4aSnFp Dqu/Po+7bp/flV2udfylbJJRTjLySqYdflsg8/CfEuRIZEyWpd3EQwEUs3hn6s8pnBuaZ5UN hKeU+Fadd7QN1Z3sxCqCEjyc2DrtntMfo9NKzaeVB3TI0I/9aipYnKfOT0NisvXMonScaiN6 x6IzChxc55okQTKoTV+GBvprWUwNrWETZZj0QyrHxw/zUtz+XUJ8nLZVAGXasZj565zm+PyG IBkEeafw7ICrHdviMCf5y8xJEv1XqFUNFjZBp5gto3Sc6yL6xqaf67ouP7ZyrJap38WVXYxN zGAWtm24UUj+kUY02Zr5a8xSjzHbOfvLyftGc4tr3Hwn6oIGU8yK/GpHssm72TW9ni7+mub+ FDN/ijvhmPPz5NAFNX3BYVGcNaUzDeO+LjrPfgbHCPKL0wHJRmzNLFO/909t9/L2p1idoQST yW1z790/q9uFXQMuNsE6zD5DtR3zferHcgemXRufBEdl6bHP0J1wYjuEBcksafPyfk4pZrNs 55yv0qZdG23fxsfHaVmeZi1OlmHc18Vs+7SU9NyIPRNqYje9N5MzvSGNLzNDgmQQ5N2sqm5P Z38N88kOo3VdG86w37w8cJegEdbuEbMciGOWUfw3zA8USQZx9ufcXKrWbJc3xcxf37fCs5Kt 6m/fSH5FvZlVoOZEA+tkfd+61AJ/Ac5783OLKl3Zy89OCaSYJbgU/pbawyDO/pSbSz1lOTHu GZOglpB2RtkFRnJarp3LxFtfOMW1NaL5VuHMcc2i9dxqz5z/NTAq3dzWX9+3wpNZM/Z6QnaF g8MsB0Ix86c4VfoU/5y/sKV+WNj15WmvYH2rab3F2CR9Gju9zgSDIJ8Q5B8RkWnmtlONrdJ/ iue463/6JE2iBvwLvo6Li9O0OE3x7wytvM7Z5+WU0gabqX8XzpgEt86osDpKkP/08080nDbJ 5IuzTXLO4+384rRnkL6Vv0nUQGjZj9k5+axz5K/lUWSXf7VsaEYUXtvuHRTPsT72VPuUL7Kn 7uy+k1lx1sOZ85821iRtky/GnuXoMK/uYnAA++UdquNS7Nv0JH/yO0D9t4nycku32S5vpxyT xG/LOD7YGyfIPyLOpLKfFIqZv2nU+dCXfw0yiL7LubRaE4vTrGsyRt+jaapWbdcP2dn5GuYT 7wxTRXFzCwln77CJg6KYlZxuvMb8ZsPgfaK109kzWpvjcHJcqd+mLXhu4wT5R3hEyrTj1Q1q 8yMmS1Zcj8+k2bNdhKbRg2FNDIJ8RJCf+/rGs19IVhm/JnQwiK7vs7LzWEc049Fpc5jeOEzX tcSv+Rn1PHPpcsprTcyZS6flWeKQf638wp85BTQn5uIEUcwSXUtGCn5BuD/HD8J9AAAAAIB3 yhIL9wEA4C+grPtyZpShgGyIXvgnzyl9DADwMrAtz5w/CPcBAAAAAN4pCPcBAOBd97R86EF+ 20h260hW60hW60hS2XmrExuOGRdOFEIAAHhdEO7P+YNwHwAAAADgnYJwHwAA3nW/ZtVmyGzY sn4l9/KV3MtXcq/YeHizTo1/+dUits2IAABeHcL9OX8Q7gMAAAAAvFMQ7gMAwLvuYXHP92cS G31i6zxi6zxi6zyT2v2JG/m9C6yiAQDwIgj35/xBuA8AAAAA8E5BuA8AAAAAQDIIhPsv+EG4 DwAAAADwTkG4DwAAAABAMgiE+y/4QbgPAAAAAPBOQbgP8Br8WXHpccWlMQAAAFjUGq9/8dbT doT7AAAAAAAwPwj3AV5ZxWejrY8G2h53AwAAwKLW/rTzraftCPcBAAAAAGB+EO4DvLKKz0bb npx763+cAwAAACwUwn0AAAAAgEUL4T7AK0O4DwAAAIsUwn0AAAAAgEUL4T7AK0O4DwAAAIsU wn0AAAAAgEUL4T7AK0O4DwAAAIsUwn0AAAAAgEUL4T7AK0O4DwAAAIsUwn0AAAAAgEUL4f4b lpJVbKWvdFRa/7jvpzHND97sQHrMgWLf5EB/bTHhAVoUJQGKr1rUz4UDT+f5LIT7AAAAsEgh 3AcAAAAAWLQQ7r+irkvh+YNeOT8/r0FWWaePk6nScYGNBp0BlXfe3EyyyjrdbPREj+5cr08P rHqDAxHkvZy6fwYE1kf3jRb8m1e7/1pB/Tnr6Etprffe0BApGQUW2jJ84sp7HD7P630yz2ch 3AcAAIBFCuE+AAAAAMCihXD/FdUUGDnHS9ucm6tN81BWoP5O8+43Gu4TJCOfoPuZCGwz6XzD 4f7luNSSk4dNbTtvZ/ybV/vsl5kZATvkCoKKL7+5UTJS481N9BDuAwAAwFKAcB8AAAAAYNH6 y4f7F54Rg/epndeyW6/ldtwq6r2Z3T6S1Xojv+dR8eBoUddIdhvzP0vZnlXWf7+gcySrddKV nM47hYMM2gVWm+En5QN3c9uvZOUnnbIIFjOqnqsxK9z3L/mF2nmF1exmwcB42cwJD42XMyc5 4Wp2+52i4WflM1qW9d9jn2TO2fsZpa8U7tOGnxafu5o7OXT7lby+h/kddwqYi/MnQY4Xn7uR 234xMCJNcb+2ccW3UZNH3XY1p3usdOgZq7fJxuzLeCO/Z7R0+vE+Lu+9md3GPITC889ow2OF nVdy2kayWq/ldt0vIRk0kkEMPSo6dyO7qjsqynWLRJJ76iW2bq/l9z4uGWbv9klJ7518jqGv 5Z5ldcWppOdmPn2qZW73WHISwn0AAABYKhDuAwAAAAAsWn/5cH/wHlGRrCIuuG6lyEF+Y5sA nbWbNi9fqSjpVOtW0mYjx71mDffEf4ayPSs+NkZDmHv5ykl7d0p4mVQwCgdZbbr/lZPpx7tl 28fLP3zv7x/8799WzNWYFe7bWFsqie9dvpJ7+crNy1fqaqZeip854daLmae1N27cxOrt4Lpd Ljbtd7JmtIyLiWKf5G7VuFOnXyncL+667KW9f/92ZoerNu8RDioQ5/PUca4LJRkEOU6QXzrr q/BuWf3Bsg//77//9rcVHy9jjb5iw4Ed5j2htZO75Uw2Zl9GxeOu9aHTxm35JMNfe8OGTctX cu9WSzDOv0Nt6zAS2b19HffylaKHlJJ8SEYJySDqaZZ6yptXfLRs2T/+838/fP/D1aw+Nyxf KSB9ejCknb3bHwN9XSV3sg8tekglhdkVpxBnHYlDUy15rLssPBDuAwAAwFKBcB8AAAAAYNH6 y4f7w+NE97+ic4p01SiHNx/ZKe2mFUY42tgpKCrvlDYW1E9yPFNtoaN1wjTiVMYfE0/JzEg1 tfOVtcr0iK1jSTdzdhQXNtRMuJXYyfzMoKT98+CkRi8fJylls0PyYWyNW/xzP0vsZpRN3kve PJThpbx6p/hGEVtVuwyP2DqPKJqHm6us0mmd8N4YttnmldZ72Nvwy7jphhOOE72F5TjY2QlI WevG/zO6a6LZE4L86bSHh4qGA9skMwzM7UV5BHZt37xWt/0lwv2cqvOeVicFtc+YnC7ziK3z iC11DgtVPC64abmsmGV5IMkgyGcEeTettDc4Kd/EylVwy3H5kFIb1lF7Jrb6067l9oyzOpxs XDe1Mj6BlFM20sbprg2M4iHW0P23iuoGfBIbzLWkT2gZCeqHHJdUEDUuswiu83ALMLb0lYj6 Ob//KdH7S3Jpr29Yio211pojTjou+axu6z1iOyLqbuQMTB1LTLibvqW3igvb0AFxRsa2ggo+ lmX3M/ommt0v7LzgpK8lpemn4Ur1iK3ziK3yiE3UOGnIv3/vNp4TCPcBAABgKUC4DwAAAACw aP3lw32m7/zdfeT4T4r798T3jpUUJ+mqqW7md9TOvlIw8DQv1l3bJlQ6+HtieIxo77VzDNB2 LfEsvcn29CvplbU2ZvYyJk0BldcL2Xue35776d6qy3apCVpUBNCuECSDGBol2rpttYzV7PPs GljNui75+4YpqTop+vck9o4x7zHvv1ZYWWOpoy2pn2uV8WMeOfFdhMxTBs4KtqVsk7yRnF9r oa3Js2PVOt22lwj306k1FtLc+x0+C60fJUgGQY6W9Pwr0Dfc0CrLKfOfqRyNX3bP/c5P3a3N paT0VbIYBeenP5oUYKp6QnanhJ2cXYxNwf3MbgbR9llyYZt1zpWi80+ZzV645/75B0RFrbG1 l45/Y1AD2++7v0/Kzde3cJZ2Ho6tv0eQDOLcdzk5UaJyVif9u8PrJr5w8JQgRyJjsrTkhPfz SiDcBwAAgKUA4T4AAAAAwKK1hML9OG1KmBvJKCIZRE2BibGPEKUwhmSUkgwiM8TENU46+Hti 4A6R7yum5HLcINkzvoFTuXNYtCifuXnKpUS2m8TnGe5n+OusUinzLhnhiLODLA1cU7QyWb+h ZRiZB4oaN6SSDI69+AfvE/U5KnJemh4tsSSjvPtqppf8cftKy5yb0wbKLKq3Vdy0xfDl7tzv 8bI+IWVBswhhHXJiqyf15+yzozMazzfcL2r6LDq3lX0ZjfU0peVUJGMY+f2zhPvyUppHdIjQ iZMyqxeF++U9VwsCKYIUHxnbwhlnMN8+xGMvb6Rn/o8FJKO4+myUo8Jeu4shdQ+ndRIfGaSl hjv3AQAAYElAuA8AAAAAsGgh3CfZwv2+m0SU0ZG9W/73HyuWrVg9w9plK45J+fYFs2/vPr9w f2LP/YBKjsx9erifGWLkEi8d/P2MHh4T5Gc2am6GHuWBJKOo4zdXpdXSTk1O5dMHyideZc/9 OwXtnUbCO7evZR3vxzveF4tzzviG2jfGWfj3xeE+bfhpWc+NM97mknxb3mdbw/f/8ffV+58b 7uu7pmlnzTnJF4X7pWcvR9sK7Nry8XsffDTbGdy0bIXOqYzP40lGWn6Vpex6gdPXI1umd5KR ij33AQAAYKlAuA8AAAAAsGgh3CdnhPsqAYpeHRktl2dzJa9nrGSYree/Trj/jDY8WkD/I7uV ebCpVZ/5W0gdFHFUCehb6LY8pd1X49yUjgiayDhVhbItoJ+Hw0nVNx7uH9OJ14m8ONvp+yOj 5QZ1YLwM4T4AAAAAg05HuA8AAAAAsIgh3CfZwv2h+0RrqqKUq7pjY8w8e36N4T4tw8giUNS4 cbZteXI5tuXxfN62PA12iptfbluemcoH71OrizRldZSsCrxa2R96Ybj/oJB+wUpcVd2nwrP+ ehHbQ9EhvnoabzDcL++7QU11EFMK0woezprz6Iqrz0Y6yGNbHgAAAFjiEO4DAAAAACxaCPdJ tnCfHCfILwNtPCgn/dTCe+PZQ/aB64W1bdaOGR7Un1J62HquKTAyduJXTg1uZ0zc0V9QNxQW maLjmO9T+zBnYnf+eYb7nRf9fMLUdE7r5l4tmCwhS94t6upzN9CX0cuxTP+BWVCXyNA0cKG4 c9SMzaaddbHU5t35UgV1e35ILuq0DuxL7XtcMvnLwXtERaayjImCXXlAF3v7y3GpmSr7RKRj v4rpGCVIBtF/rbCm2doh3DRyKKL+PkHeprbRtfbzqQV2BzC3MHpMkF8FhWZQJEX5xF4t3E/x 3LHXyiT2i4mzUN5/Lzsn19o9xSbxQkwXs1KxtbGjvF6kUdLn2SSjfPK5536jUsv17Mr9a/7I JhnEuX/lZEeKnrA1jP4ijm2fpZSsYiN10QNHZy+om1da73E6StMyTs+1/kzfWAHCfQAAAFjk EO4DAAAAACxaf/lwf3ic6P4uOrdET91MTFCfktweVD+aTysw0bM8KOhuntIfTR8rTA0xMHM6 bFDim/tdzvknZeXlDuZOIkoeWvENbpPlWMPznOztBCQsdWI/i2ZPuls7PWysJUR1xDwanGMa POMbbB28VOQUDsp5mJfcSe9lUJu/iYuNtdORWCsboR3QE1N/vYgcLxu4mpTb5qAvJ6lmJerS 4186UjL4lCAZeaV17m6ugvrJzlG1rDKwRc5hfpIC1gbR/2SN+4Qgf/J3tzmp563iMlUw1sLO U1Z4/47Na1ZKhOgETgw071Vqoft7OmzeaqQTWuE0echRNE9rUzGtWIOES5x3wd9IKyk1VRXa JRNh4E3zjG/wDM90tDM4xKckYlPvVXaTIB8UdQ056Ykd14495THRW5VnfKiyos6Bzdu27OE/ aNHuWXItt2ecIEcL6D/EpDd4JzRYaMtIqFmL2k0eET2k/Kf0Xs559v6Sl5+idERYWD9eO6jB M77BLaLEhHKCX0JPwaspgPX1gsy0RGMDG4lTIabxDe6ThxOc7mBsfEAs0LLo+1SSQZD3CzuH nHRPyBsl6vpOLaOBvoHoka2bd/NtUM5wTPospfN+CdsEkgJMJQ5w/cd/cP9jtZl5x91MhPsA AACwyCHcBwAAAABYtP7y4f7gPaIiSVmMf+2K1ctWrF658aDQ6ZGofMJKX2XTii2rt6ioZ95I So7XUxZetlZgnVhSYOf9ApJBtPUE+5htX7Gaa6oW6/41251s2u9kzhyCqPa1kJ+q2rpZ9ahB xeRd/3HRkRpCrId2mCuf7k0l7xa0dxqJ7GaWrt0mvUm3OfvcKDOYLmm1klnN/fHkuFtWb1VV z7yR1D1t3B+D/Fwld0xVi10r7iFjW3ja5NjatWuX7bRQPt2bOv9VausO8jbdtmL1cvbys6u2 LtvnZ5X3ffYsT7mc15J7Yuu29WyTpGTdYpvkI4JsNJCT2slssG7ZCv7jfgMW3hEnhVZzrd+/ 3aw7tPYuQY4kZKer7l296qOZxW8PHzWkujTMGLrvBpHgIMS7jzXJbcv2+Vnn/zB9kkSVl9kJ jg7XCW2QSAk++7BgqtljgvzSSVeRZ9NUs03qubq2oWYqB5et2rZsv/+0nlPCXRREdi1bcXDt LhfbznuTn3kg3AcAAIBFCuE+AAAAAMCi9ZcP9y88Iwbv5XdcyWq5nNFyObN1JLf3aenAw8Kz 17Na/shsvU4deFrWf6+g82pG65Wsjnslw89oJIMYGivpuZnNUYt1JLPtduHws/KZQww+LD53 bapl6/Wcsw9LSQaNZBAko7TvLpXOeqjtZn7vWNlE6dqOEWbp2rZrWWcflQ//OdFb+fnRws7L mWw1YDPbrlMHnpYNTxv3SUnv7by2qRlmddzO635Qcu5KVuvkQPNepVmO93JGyx8Z7XcKB57M csjk0/KhB/ltf2RxTPIZ2yT/JMhHBZ1X2fq8ktc7Vthzl0q/nNk6kn1urGTwGUE+LRu4n9/O frxTC55z9kHR0MwT+pTov5VLH+GY5PkZk5x2UlouZ7Rezeq4zzy/U5McLzp7LaeVbRm7HhR0 3y3sGpm157K+2/kdf2S0jGS13S5iuxgQ7gMAAMAihXAfAAAAAGDR+suH+wBvHsJ9AAAAWKQQ 7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMAAAAALFoI9wFe GcJ9AAAAWKQQ7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMAAAAALFoI9wFeGcJ9AAAAWKQQ7gMA AAAALFr/xnC/feTn+ss/APz1NFz5tv1p51v/4xwAAABgoRDuAwAAAAAsWv/GcL+b0f3W/3oB AAAAAIBJCPcBAAAAABYthPsAAAAAAEsVwn0AAAAAgEUL4T4AAAAAwFKFcB8AAAAAYNFCuA8A AAAAsFQh3AcAAAAAWLQQ7gMAAAAALFUI9wEAAAAAFi2E+wAAAAAASxXCfQAAAACARQvhPgAA AADAUoVwHwAAAABg0UK4DwAAAACwVCHcBwAAAABYtBDuAwAAAAAsVQj3AQAAAAAWLYT7AAAA AABLFcJ9AAAAAIBFC+E+AAAAAMBShXAfAAAAAGDRQrgPAAAAALBUIdwHAAAAAFi0EO4DAAAA ACxVCPcBAAAAABYthPsAAAAAAEsVwn0AAAAAgEUL4T4AAAAAwFKFcB8AAAAAYNFCuA8AAAAA sFQh3AcAAAAAWLQQ7gMAAAAALFUI9wEAAAAAFi2E+wAAAAAASxXCfQAAAACARQvhPgAAAADA UoVwHwAAAABg0UK4DwAAAACwVCHcBwAAAABYtBDuAwAAAAAsVQj3AQAAAAAWLYT7AAAAAABL FcJ9AAAAAIBFC+E+AAAAAMBShXAfAAAAAGDRQrgPAAAAALBUIdwHAAAAAFi0EO4DAAAAACxV CPcBAAAAABYthPsAAAAAAEsVwn0AAAAAgEUL4T4AAADAa9L+tKttvPsd1/60860v1F9A25Nz 81rwJ+fa/3z7s50Dwn0AAAAAgEUL4T4AAADAa1L/+w8Vn4294xqvf/HWF+ovoPpf1+ez2tXf 3kC4DwAAAAAAbwbCfQAAAIDXpO6XXwiS8Y5ruPr1W1+ov4Cqr+7MZ7WrvrzX/mfHW5/tHBDu AwAAAAAsWgj3AQAAAF4ThPtLB8J9AAAAAAB42xDuAwAAALwmCPeXDoT7AAAAAADwtiHcB3iL nra0PqghrtTUjbW0vvXJwGLS1va0qf4GUXWnofFx29ueDABMQbi/dCDcBwAAAACAtw3hPsBb dDmtJFtu03Y543PZeW99MrCY1FT/Fm51Yq2gm6f3+Yq3PRkAmIJwf+lAuA8AAAAAAG8bwv05 jNXRB2wMHaX5lfinuLn59ha//bnBv0l5eq2NqRG/iK6cQUttwc3X3f+vSUUJQh/8Q+hUW0b2 2z/Yd8blM4EJGjJJFAWkAAAgAElEQVSsF92pgozEX972lOYx54B4DRklmeMWDhH3m6rf+IjV VT8HGvK+t8/M0aWb9rKdlKVVWxsb8ovqKxi2NxTfettrCAuWEZljQFESlzQ1cPuqmXj01ucD dDrC/aUE4T4AAAAAALxtSyfcv1dYdN7fNsjAKMjAYJo4/5ChwhlhXF3jzfggUz4pQyUpZz09 f5asiJh/Em/xQFoe1ubWWjrFGBgEGZgmu7v3EQ1jbXQGnfhnTEQO84isK5NTfqyn3y2rHfKy jDSeOtIQU4Ok8OSfq+rZOqy+FBKSb24QZGB0xtKutbD4RhOdQa/9PS+l2MAslPlE0xQP9z5i cvePpmuF1GZb83AjZrexztZV6Q0XT3s3JsZ9ubCbiGt/z0tmG4iNtXtTauZLp41XsgovRHn0 E6+8Y0kVtT/QzUNKTm6LcE5V+uXXfULvlNYM+JiG+pz5jlbx9i6qd86NtIRqZ3N/vVMuKiL7 /0coJDLgi1fts/l+bU61S9xXpcX339Sc46sMVSlCu7cqud5uoL3xVWpsvJ0bk2HkUpuS9lP9 c5v9GJN4PiXii5rnNKii9ga4uknIyu8Qyq/LGvm3nFxYiKpPAuOHMpJ+fV6DgrQWT1MDaXGJ o6cGGovuvf0JA51Bp7ZnefkGaVqe0bQsC2y6nsue89Z2+IQkaVoGaTkmmaT9Fpte5uoXqWkZ xBRwLrz6el79xZCgIC0r5i91vcscqdfKhv8kSAZB3smsPOfpFnSK9RSjgHyn3AtO1rRw5kC3 qO19ztYhepN9ctJxSXcse5rT+06E+5UXTscNZaX89vZP2UtDuA8AAAAAAG/b0gn3b2Zk1pie UDgmoHDsmMTWTdvWrNi4db/CMT6FY8cMTO0aMsqntR8vqvrGSnQzr05eYvJrv1/7FTTdrUyI l5ITW7Vm25r18qpaFUW1j1rpDHrROS9bkx2b1/zPigNHhAKDQy9V06/nVTboSWkKHVM4uGvv R6tX/335gZ3L10uZ1Gfmj051WN5hZ+twZNdurvfee3+FspPfp+V1DHrlN4kh/nyiqvu3bOBa s23Tbj0trYqiuketdEZDxQ+ZsSW2Ztb8QsrHjikcO6ZwjFdVis/wlJ/z/h06JkZE9oIOp/Kb xGAfHlH+lcs2bFh35MBEh8cUjh1T4D/uYGpVnVVwl976bOELdcn7TLrWwcisqvstr77mNV+c iQ44KFlQ/frDfZhT/Uihv977CnGvIdyvHyn119lhXJEY+wYj7PQEmpnUViX3f0e4Pz8deuax dpSywjnaVH8WGhnII1ZYj3D/HZSXJWWa6GbdP1ebonPBbqZHdQYR7r8rMmmu2jJ7Pnpvxf+9 xycVMRDWNTYZ8uaEmksf3fC/H67nOqAlefqroKAgXYr4ls3b3ufau1NQ/pBhiUfBb1lldBfj E7wiIhtWrvp446FdykGacb+UDj0jyPtZ1W1uHh7HhRWOMEnxKaoJnLTf/v+p6ud+nUAyCPKH VCLu2Ps79x6SPCCscISXf/fWdf9vxaGdPNJHhBUOHOLZc+Aob9DjePo7Ee7npYsZJ3nZnX/7 p+ylIdwHAAAAAIC3bemE++y+87Dz0Zaw8shk0FtmPvq4vv5WJe3buCxCdedhVcvK+IwRGm2E RhshaDcbmsYXfif4s9a2sdqqKwTB7OcVumIpomkYnNZRyU2vHaW3/UmnM+htYw0F53xs9TfJ lxCZ00K6x1mhsScU1fZLZbtJrN6qHBcV8Svn0JcjI+PE1v7X+//4G69aZULKo4lAvJnOyHQ3 F9P2tff8ntmy9VFGSKy8qOjhbc5hlXebJn5Z+21clPfO9dz/998ipxYa7tMZdPqDSnqlDK+l JedzEwJClOXlVAwvtNSPt9MZdDqjpWW0rnpqDWm0K5UVN+ubn7W3Tz7rzzb6aG319Qpap71v pMpev+jc70tZ7SuIq7UNz9rbpk+gufFeddVUtxVVd2trHzbUsPU8Ge4nfVtdfY11Bq/VNTxu ndHbfLU+qq29QTC7Gqmeu6Bu8/3JcWm0EVrVvbqaW3W1t+qbGPT2lxq9bby56W7F1AV5tari dkPzvcq6h81N43MsDq3ydn39Y9YhPKytvUHQrlYRtxoabxGVV2m06zU19xvbnjTUTFzt12tq 7jfTGe10RlP9zcrKEaLyZl39WGvjbaLyKrND4mpF9cO2lqezz/MF4f6fbfTx+tobbAcyQqPd qKsfbWVv1vKoru4GreDzNGf1rVrZIQGfzdWYPt7YdLeKxtYhca26+kFL+5/t00d/0thwu6pi ag1r6h4mxy443J9cHBpthCCuVtc9bmd9msUsmVtxhUYboVXcqKkdpbf/Of2kVNyeraDu0+bW B9XECI1GUPQCjRXSk9mOqLLqdgP7lTMZ7qd+V/W6Lm/6k8Z69sWZuBgeNHM2a+W4VB40tz9r bblfWXmV4DxeOp3R0vyotpp1yhpGW9vGm5ruMM975e2Ghsfs3ba1jNbXsr1eiOvV1Q9aOc7g szb6o5qqa5MDtbf/2dJ4u7LqCo02UlFxrbaR442CeY5Yh0PQRqrr7tVU36ufcUSvzeQBJkQL 64RaG9azreTV6up7Ta1sZ5AV7tfl/DZxCDTalQrarcbmJzMujPHGxmmX98zFWZh2OmNy6ZgX WM292urbdbWck2x93Fh/k+0oRgjiGvvVzjJWV3ezgjZCI65WVj9sb33W2nS/pvoqc9nrH7e2 zji/FTdqakfb2sfra65PvhVMNp64zOprRmgc//5eq2scn355tzysq73O9tynTU33q5kn/UZ9 w7Q3ijnV/dIfGZMgt2nLpl3/WKuUYZX1eynJIC48JQbvuesIix1au0HE4ojblyWDzwiSQTQ1 uLn47BdOCBsYL5yKgx8R5KfmMopqNoUuDaxfDn3uZqkrI2uhksooG5745eXoxDPyO9f8z/9T 1pwM96tzj231dS/+OZtkEHWdMV4G/ylRFFJ5jSAZucXVPpaKfCELDvdbR+vrb1Uwz+/DlpZn bC/JqzV1j9j//Zo8ZWzvOXc43nMmLm/aCC3+jIBWmL1x4/Mu7+bGu9WVE5fK+MSl0sp29qtq HzS1zDIu6/yONzTeqWReJHcaGx+30RmtreMTF0NF9b3G+ods1+SMl9U8VX11hyCflvbfo9JH slonXc3uuFt84c9yhPsAAAAAAPDGIdyf+eiAjYXZfq6Ply1f8d5//fd7f1/x4XJuLi5uLq7N G7h03SMvLXx767vUik4dwb1r1kz08ypdsbQ+rEkq0DV1lDrZTK8dpdMZdKLHxT3oxNGQmIKr zdOj0n4LI2v5I5aOkb9S3bVWCDo7OHVz7ix0OTIyXXP7Xnlzy227zM3M63LpDPqs4X4RQdHz 01bMSCFuN7U9Y+ZBbeNNTSN5tByxQ6bmry/cb2487xYcp8mbmFv1YCJVyUlv0Zfg5lo9uYzb 922h2MfdaqibfNbDKnqTmqTUZq6P/vH+sv/7r/eXLf+Y1Zh760ZeDc+b9cT0CSQEnJE9Ntkn 93Zhr1M6hR5qFPvk240TPU+G+3ZukjLCXFzcXFwb1nEJ6rkOFr70XjpFtJMU5Y1c3Fxc3Nxc 3FJzF9SNjxFnjsvNxcXNJRBmLGdkomNuH8GgN7/U6LVfx5zx3r1u80pmn4f5tlq4J4QeMShK Cf2GvWW8f5g039TicB20srMfZD5aWE5RV9rIdZhvk7GLl/GaQ/u5uMQV5VMDKn52Vt2zZjP3 xH8m0xkNdEaIpdahvdyb9mvqWvQW+1tvOLiP2eGa/buPF9XkXJ19ni8I9x/X0L+0VpfftZFt hlzKJnZN+ezNsiuMdU9wca3+8B/v/ed7yz/4YPVcjen/9A/24+Ni63CtqLhYet70zwAYdPqP Pg4Ox7ZNtuRR0i1x8F5wuF9PZ4SYnzy4l5uLi3vtBh4J/YF61sZBzJK5O7dwcXFzbVdU1Gqj Nzym0xlx/iHSR1nj7rCdraDub8lFmeLrtnzEteK9v33wt/9b/iHbER3kt3I8w/bWNxnu27uK HhecuLw3cAkZeJLFL79V1A/e9vZsi8PNxSWhrJiewtmslPa9o/KOjzexHm2+WZIdx8t7lJuL m2u7srJ2O72R+VFTVlK1tjg310fcXFwqZg4t1JovIsM8d6/ZuJKLm+ugjYPTMHu35TntNqeO ca1ayxx6nbikZGYex0cg92j0OiVh0U2sgZqbnmR72fPy7ebi4t6+VUjb50FTJcc5CjajHNjD PJa1XNzSZpFyUiEWypkpL7k+L1LzRUSoxy7ujSs/XPY/f/vg739bybaS+8WkgoPzGPTJbLro XLCb6SGdwRQjQx6+3RPvjVu5DHyTvqmc3vPnvqe9eNkv73USUlJZea/wSXMTnZHtZctzdGJc 7tVc3PtUojSOO5icDA7OZ5tkycBpew2u1esmh163if+44XBT6QPODrtN9HT2cHFzrT1yQLq8 kXqjIPL/Z++845q6/v/f7+fz+7TfftqqqJW6996IgLL33nuvhLA3hA1J2HsTEkKYGRcCCUlI 4IoLENRUa1u7bG1ti+LeW3t/f2SQAFaw+rXjPB7Pf7x53/c5533OvbSve877XWFtvEsS9qDj Tc0IgyQIdlaf//ES6SNgZ+fB6xR8hrYxXr9iYo5Mgo43NSMwjLQzvo2wXL1o4i2xctV8Tb+U M7ROxbHUt3u6msrdO5afW2q8afH8BYvnz7cLioWbZx4Wsbhvt2OPZWLY+rV+1kl9eSIEGr4C MYv0t7qYmVmYx6S+irjPbvR0TzT0bssbRpgnxRef0Ya/KCHlq/w/e983Ke7T+4IxPmvF82vH INVcI5YxXXQWz1+4eP58VTs/Vg1twrg5v9TSaKfcil28WzMqrlBuMXSdycbFbVq0bMG8ue++ P+dDheW9Q98kL5sqEdmLk1L09ixetnq/if9pIf0+DCP0el6Qk9r8hUvmz1+sZd9YWDu13VWr 52v5p31JZ53GpiTsEbvdGJWW9SkLRtpoZ8PNly9csXijfk5WBD0l3Gn+wqVT250FrK9uQaJf i8qLrLYunv/xYqWFYvauVc+MPf6sEYj7AAAAAAAAAAAA4I0DxP2pv16lNp4owtMiEvHaK9Zr 22ZHJHDweA4ez83Bj7RCN/mzbu4Jhz9OKhNkZ4v9cPCZzJTQOF3TUFQEv/6V03ewf8nNJbsZ moXlXO1hXSxML/Gxi8Ikf8fmTdmtSao2sEVbGlVWd91n0bvNjSxsnasKyPI2YwUF9e6b97sT RryMbQ3tUlOLL8FTxH0hjLTisYZuqcFhJ7mT+/OsFx6rqzzTTB3jzHos04v7MPxZckGdq1xq HXbXRXIFB0+QhhHfHJmUZKpq7xv7aXOb+JanvfBYXeWhPHyFk0+I9mrfsCRmpsSYk5fbT2x7 JODL/D9kw8PB3hFGRlE+vvVSnxxMQKKeqtre1XqoohtcNgLDCNz9ZX5uzKpl6mo7vDx8yxPw HDy+IwWPNzOODA4VkF5tBnsuEOsGc/GcuESy3c6PtAJfUFCXfxMqLzW0i/OUtMvJwHNCvYPV d67btccRjUNg/qybZtSxQ31QRhoY/7QOSXCSSaF+qD27t3yoji/MEMvoT3rg86lh8eY20b5+ E8GJwqTZ2oR4enS1cR/19Vwg1rH9vTF7P1mzXQ0TGNmYEpJuZ2m7VcvFwKYgLZ4e5R1paxca mPmTsPcZo/FYcWy0lY3VNoN4u30RQZHUVDwHj+ckp7YFODpp6SYmZgy3TxOl3xP3O7rHCMGW 5j6VMdGyJcHBR2Va2Ya6e5FL2qRaEvvnBtIRfGpznKvuUkMsKqB5whg/SGm6KLdix/Izy/xd Iv3COPgsqU1CNdotYL8mPo94vkti9qAbHsJ4+llZpaFDZK6KnZxQe9bt2bZqrXXsLMR9IYww GodDPPzMdKxdo/or6q8KuE/FPwl67zOpR7ITonaZoGyt62vqL4lTVHW2n60q4eAz2mJDPJbu io6fpqDufVbP9xU5PAIer2sSYLkvPmZiyJyiUlEzU1FoI0StWqymvsPHy68yEc/B46FkPM7U MDIkvL9hysewl8KDkbKkaBffdLngcPBxxR5uYTZmmVnkBwKe1JJ/t7mWn51bZ2Mc7qDm5hSO 0dnt7RnekITnBIeU+llgssj3xcZs1i/1FZ1YQrn+Tl93C29Lb5Tx/pCA9M5MPMfXMwXjU1Ta LhkRsbDRzdXH0joXn9klaTq+CuUaoLmfkE/6SVp74Akf/rWmfCA3LsPYLUhNOyPcym63SWx4 EAmPJ4dgky20mhpIl3gwAsMIxPo1K8hFyykjKky8cjpS8OUOluarFxtY6peUv8KzPxN6bzEZ nxVkc/GRYTuM0fbmBXKLVlBR+SWdo7BzPyXUes4K3W37oyKCSHg8B59BSwyJ0jTKTMKN0ibc /pqXUeLvEuMfzsHjpN7iKwNdA7X2EwrIF15UmOF34HRfLE2OVLFLjggiix2m4jk+jvZb12zV 1oxPa5Aus84T6allLsZJ4ZldOOlA4rGNriYG+z2bGxRSrl+hkEYKksrc/bzXaeXEmXnqmIV4 e1Tg8fREfIK2RV0B/ism+2IjkR2HT9i6YqfG/ihU0mAtaay372Zj7aH88HANLYMNG1BRGV2V jdc4PUhn80hKdJSxfUlmIlMaQAYWn2Wi7+6J6qmmyA2n+ydS/eGkRKKf3kotD7yZRYiZSbBH IAefxcH7BFlgqISy8ZlGRizu26sa29d+5mhsqO+d70sZpw2cr0oy2aid4u4TEoJNfxVx/2h3 gKuLilqITenP0hT8CCS613rkx7yyE1UDd1remLjPu0RtHM1LJkc571/pmuFgEmahH+TkVo3P YuMjYw18iFlpX0ss66hWATgfzwq5FUtBByXaGGH8Er4Rdj6EYQTuvcmgny4g9OAjQrYZBjla FsoZCyuqvmJIl3dH2+cVqXhPZ4d9bieE7fdgGOF1jzUS4XQ8J9hK08ivMadyopM9zG9qKoXR sUTnLZvdvKN1rVEmlnGB4Zx0HCfY0d0jil3RiHC5t5uqe/ABDnt0LLfv8bc0SQ7PYuPwHDwm 2tjYy8SsoUb4fHanWFhf3YJED6iCrwtrOIklUgh1IcHhqjrBfsQfyw8DcR8AAAAAAAAAAAC8 UYC4/yKbmxTogPtWNffYg5TJ6fj/MMKHXcwjTibGFo5FhLpX98Okn0iLc9MzLA32jTd3jA7w aiFCcpodjMDwMz48Xhbmq2URFxjxWRf8jAtfSve1U7eIj0j6Sc5srKCg3n2Ljl/RtSo8wdIh yMuxrR5CevsUxH2x1m/hX5CAf71FCKYX91tJNH9MuIM5C+p++IJdpbeaINhPY+1uV6iyalKV 1Jfn3Ofzr5NLYw3tsd6B3Or6iRG11B8I8fI32qqHKpYX92PXfKJnYldXUn2+B0Zg+DEX/jLT F23tWZ1R8spVfxEYRto7fowxXqAb/AJxv+dya4b3HL30lMTj4qKpQhhh1nZHx+SGRdPLKAj8 O8l8pud8ZlKpm0l4IIZD4T2S7EbnjTc1dPjaGS/UzS/K+BKGET7vBrk029AuzBvFrJELDqtp KDEqzdYoMCjnHI/1CIZ/zc2rtd2wzxzNaWq/xqeyfH1dN6xwQGd9y2M9YpXV+gSG2QV9AfOe wjAC17X4etqt2eTjguY2t18X5zPh8W41Ftf72/nboam5pCmR/B1xn/1zTRnV3jYkMfsrhVrE rE+zMkvc/Qqi47+B+c/kXf1+zn0hjDDrGgOD88JDeuvln6PuC+RSiqdNsEfyYHPbXRhGeLwr pJJofTtsSOQgpU3m4YeivFpbfcNdy2cn7ktWXW5NUGB8EO4y3PscbjmUmEJJxApJHQjch8DV xcZBlbHRn02+i3+tjYjfoJWSOI24L2NmOffxMWs/1jV1IJXV/tQDIzD8iAN/ke7lb+lFxJXN cnn33oEaWPY+iZEJfZR2+fn6rqyU4uud4BEs4tEmPa3fxqDi9Ldpa1tFoj1balvHe2CE0fZN VVZzeftj4cTZlIed8GkfI3uNveYmdqkxoVzxfvPmusHyQgEJQuB+BG456BWUZGOfkU74BpYd YOr+sb6o3lXXSSesh9x4RaFpGj8wDLVtnamVWYpn5IHWxiswfKOt+1RW5AEa7YZ4ibYyvo3Q /2Cnd2ddrbjbT7nwxaKMOkxAdUb6dF+kXi8zy7mPDbWbs8reLbCnTTxA4b0OxkEvcw+PEEY5 Tbq8a8n+QXkR4UJyh3xSph+JJWRPK4xH6rHW9nuz7R4LOpfptXOBdU1FgeQPCh9GSAUNoSH5 CVhZQ9dqsylBftnh2GMdgmcy5bSLfbk4DW/lnJqaOdzereiZdSoLH71ujZ6ZbqQrurOi4mcY fsiGv0hLP0ypu9ADIzD8sAP+3MtAz8CukFB+c+I5ys61tHE2seV09D7rhxGY/V12LsXPKQWb d0HYLcvd9JANf54Wm+HsWZeZfrZ7yojwXttXq7vomsahY1kV4sMHzf3p5SeI5Bk/CxJxf6+V PfVRRlqwhXWYUSgjm8P3V9umGgDFpuYlvJq4LzqXX97s451g4hzujMmSL7fLmND6r1MPfBqV CJcJb7ZMEfdbBWcr6tteuaBu948NKU7zdey0tEO9/NvyK6/Afb/BnSfSSkbrK3+G4Yfd8Bfp qDSnoNYihRLQtxobDsagstwsyogtFxV2Bswk537zgYy4oH3uJ4Vy65MHI7WRLjZhrfLivpjm ti/DtJV3aDoY2mREJsMNHYigH2FUM7MrzzTJjhfkJaruN9y0OxydPNIhPoNIPxEdkm6t7pdE e9r3wv8snI7pc+4PjdWSG4xWLzJM/TSTB8R9AAAAAAAAAAAA8EYB4v6LbF6nuC8QPOxoGsor 6iUQuGIyCFx3o70G9ri0kj/i+Sq1g+O+z3Ltxr06NnnZRRcnG/Q96OLADvrGlvYlOWQEluy+ T1Q1D3J36WZNWErE/cCiaz3sz+NCYi00AtC4S738Z1PFfeeQ2vSJPl+jNp4skg6KQOASikVN TddmOQqxuO9ibYiNkHMVHJDo5BgZmfEjzJdsZIZ5N5ito4RcvswmNbXZz2jTWnty6eSxv1Tc f8JkfZNmp2YWc7SeOvnX1sZTOcFJGeS7fC4Cwwjc/WV+fuq2HTm1FT8oCBNFOPPgiqikH/7I 2niJuM+/ySwvUXfNCkOTJoJMGFLcbz4bOjvsAwuCXbomy8GCu6wWhmOsoKH8JxhGOlm/4lzV 9gZC1TWT9SxW0+EEjO0ue2E35QYM/5qb1xq4C43rvtMLIzBdiIlMMdpdROq+L4QRuK4FE5ks L+67urrt2JRe2X1v8qSU55lgKqLjzk7u7YvFfX7z4dQQ67UGhakxTIL8CiRwCYQKR3SqoxYZ 4sh9FnqZuM+DkfJwVyOHCA8Ud7LDLBo2zHOnHbk453s+/ITRcTbVZo9p7DC5aZKTa0X5Fc67 11rHzb6gbgMdHZ3h4Hu8j/eUjY/fvmfHhm0BkUV3hILfGGlhpqjyxKwp3X6N4n5u6s5tufXV P/HkrxemG2Oq41LOz2oggu5fiHE2yyzTglCtU+aFgkrEau0obKr9WTFV/bcxqBBNVXvXyONw 79MXOxeL+8a7DeISs6YsFRjpgxE2PnafV17k1IXEG28ujV5sVpyf9plC0zR+IMZPda1tZO79 3u7p24VYP+PQxqY+NXGxcmMp/4YF3X1xV18fMxP3U6J91xmzeI0T714+jNRFe9qHNuLLERhG uDBSFuKg7xDliZ6yvDPbEkLdt9tSyvLPz7aEAKf7YllShJZ7bkyE3HQXnmqnXZdzdTrEO95B C4WevB64mQRuqI2zLZqaT7yv4Jl1KisrctOiPT5Rp9pp0zfNhZHSCFd1s8jQ8BHJkZqen+JQ YWbGvsG4C5Iy7M0s7+AobY0MQhZnymok2tglBHmQiRyFTCws6FyW1/aPd0VGpZygv/KsyYv7 NazeIBe0gamLY37Gxo8MHAu/KKwlv6q4j0AihESHY/0tVbWlNXVN0DqBDQl1Z2sPP2ifqjIr ivvyvJK4T0px+nCni3ewkDL1TE/ftRY2aa8aytupKGnKXMfGUdy2agYVfcHokV/eb0Lc/yJY e+5S3SxC/jfsF/nMS9ypj3Z2ZTbKXawu7Ay3sg2rftrX8+LOTEUs7tMOXSTSDySVcbFSotIq bHb8a3/M8eQuIO4DAAAAAAAAAACANwoQ919k89rE/T7hIyb9qxQvvcXrV8xTUlZSUlZSUp6n pPzB++9t0/uD4j4C995i1ududSaWpH0+TdO9N2nVmZs3Ozm71BfLCtZVVBgaeJpq4AomCtzJ i/tIa0m9rbOTlnFzJ3SfGDdZ3HfEVKUWyQS44eBAv61KykpKi+YpzXv3P++/v84bHXZslqMQ i/t7Pnl/7hxpfJSUlNdpYhPSf5wwEzzgNA4kBZh/uHjZRBjnfTz3/f8sNaievbh/g8zoc9+8 xz3uKPWlOqws537dmML1/wNxH0Z6YaQhJVpNfZMsMkpzDV18Wyq7bvMEs08QXJS5xy3NH330 Zb36NcFIzTN9sGlqcLq+yCvM3KXf3E28OGtxHxWmbcWGex5N9kmlmKDLo6f26sXiPp3Ui7JZ 9//mLJw3d5GS3LKRskttU0Ie+75AztXvi/s9MJLubbhu9YcffjTVm7KSkrLSupCEpJEO+AaJ 1uu+Ybd7wvDU4NSVzzrnvgQGHJxc7GTN6uHeq4z02Lx54byVprb+oi7egxR3ExufYnzVlFte o7gvzrlPUozMK4n7XZ3ns3xU/rv8k48++ni6MK5ZreSVXP61Yi74b2NQ+aGOxWUvcS4W96Ni 4rop0xnwYaQuxts+lIIrn/rrbQbM1DfKzow7qlBuhMYPTCxwsumBFetIK/KIBX8RZGuyfvnE 23uOShI+9QSH82AWRVZfjZmJ++KCurzWOwrRkBP32TCS6qG9etVHL1ze68OS0k5MydH/cjgw ggu03bZJzhVn1HIAACAASURBVNUq37CovuaJb3j97vZWq9796KNp21VSXq+TlYb/WcEt61RW Hk5Np5VHeUE1DjHNVBMjf1ujohI+0t+PCEhVugaBjmY1NTKDmgZ7G41335s3/ZCVtukaEhSq F8AICzqX57VdO0ZE+Z0iKC9FQdw/ihRmxnjor9yk5vju5uwI2i+Ulj8k7k+ipoHmb7z2v6ui MM0/1p940+J+Y4rTKj92XcV088K71FibvmrNWqUP5s+bLuBLlZSNMaLmZvnl/SbE/W/itLe4 40+3/07JkLxE3aD65Az584t/QNxnHLtbS2rB2GyZs/CTuQuUxcyZt+C/776zNQSI+wAAAAAA AAAAAOBNA8T9F9m8NnEfahqM8jRYtjk8NetoI2OMwRhjMMaaGWOxrkbmrm9W3GezxwswBkpL F7z/vtJcWcG6efPee++/azY6Y3JlGdsVxH0h/wc8Idd6yxY77JUy1GRx38AjMypZ9r/Ejzic 6xBjjMH4nswg6+zy9nJvrpkq3b4Esbgf4ONCLJLGh8EYgzpvcnly23gbWChPr50r/ONI37RI bSiUUymueza4UP7G4n4/jAi4Nzs7L8oiwyirNrdwM9FNy3yFtDx/I3E/3HX/NjtWY/m3DLll I+VSp3zNZ3im4r6pc2pc1lRvYwzGGAO6weU+6ntD4r7wR3xJZ6h1YQVXFGCxT3fbpiU7PPdq lFRwPvUzDQuPguqnVk7+s4r7BB+VVQ6VhKzPpgvjRSbjGrd3UvnWP7m4/1sf/ITTdQViSkbR whjLD/XbqRvg7cP5k6TlmaG4b+ySGY//neX9+BXK6vbBCI9zFYLkXKVjVTU9bWxJUpG9390+ 2kUrCz9tu4wxiHVL4VUPz1jcF34e5uNhrhsQUYDw+xBSvN8G0/CgoMMThwZqGuz9QrRNmxlt P0/7lmCxJn8ifSPiPq2xNsR+14dLdu1IvFLU95TxWsV9+rFfq1uaLNaoOBaczj3w9sX9vdFR 4T310000kzHG4jwWyv/N+nuI+8TqEk97+zX6ecn8XyoFY0TBGFEwVkrtD9T8t048EPcBAAAA AAAAAADAmwaI+y+yeV3i/vXKchZqn6MPfpTeeUcmNHNhJNPf0trjjYr7V8nMbqcte/XsCyIT 5Cpb4jn40DhzS3cd08627odCGJkk7sPwww5Kb4y74Qqt+iRbi/1Scb8PRthVpaZuKf4evGkK eMKdJmrBU4rizoQXFdRVgISvRbkE+MScZnInlMHu7rE8/30b3RtfIS1PC3QWo7Vc1bO5qvpl mZTfqrg/DT0XcuJTbKwCvBN+gnnPZtdifY2+VZijOanhd806xGl5UC9IyxNst8te0E25Pmtx 3ztAdV9dG/vBZA2xYvZpeRjHM5IwO/aW1dX8zPvdschcvTTnPiMtfJ87LiJ2mpQvcjxmdJxN td5jNn1anspXTMsDP6gs50WaWAbmle7ZYuvqiDJGx+gutQzMLt2zDxsfC08jIv8pxX1Bz6X6 3JD1RrmZqadmXKD19Yj7krQ83nmR8V9N/pU33lwmScujUBF9RuL+dA21cT1cgl0tCXntk8qc vG5ek7gvgBF6CkbNjRCVMCU4r52OryL80HZWYQnV4uBcSQmOcZv45wyYobgP323Lzbex9TGx odf0HnLXszC0q8iulCsJ0z0QHJ1hvR1fzX8yw+8Wb0Tchw79VEs/nFR9MIf3rHkEgSaJ+8ND qam4fVuS4oYfN06I77chEddlr5dTTFfGkOQisbIwpuwgtnOSgn+N1MV2XLvFPucUof9tivvC 27Ruvrm2e2BIV/0MC3G/qrjPhhG8j75FAPHPIO6fzYzFu7unejWfbzz5G10a3kbO6UiDf+sn AHEfAAAAAAAAAAAAvGmAuP8im9cl7o8VFJLct+ihS69wOOIrt+ns4wmYAsPdGzSt3qS4zz5b UJS4caljZKqIzlH8iQmHRkbsW4nKJN/i85Ep4j4Cs3+pKiFp7jXR3rZyg2GMWNyHYQRmnUqI ynawSY7Efz2RCh9G4L47HVC9xq6AgDcm7hcl57jbOAdmXpZWSb3T0nIsER1vorJ8tRVxGnGf QDBf6RRbeoPLkYyIUtUWEJidXHBOXH+Vzb1SnOmjauCPRvMb2uTvHSdRhFhUSWLeeR7rEQy/ RXH/YQfn+8I4ciHxAktBbjifGZ1kZ4xGZY7D/Oeza5H1aRwmyUI/yC9xuENO8OLzblNLG1Ch rYVlZztghMe7QSrGG9ilxCccaeuSXzlnslKL7IwDUARZQd1ZiPu+HnZrNvq6YfgtspTcwgds 6GgsKs0nnFlcP6VQ8+8U1OWN19ezXAzcrH2byiVlYCc6WZjLiA3jNfIfC+VctaV7LNbPSEg6 0QEjsDjfUXFLZHjtRFnUlgHvoGQbu4z0bLlyrOKqvyXkwISemrqfemCEx7tSXxypb5+fgP1U LjjX6ipa3KyNd79SQV0YRhikgWRXnb1WtkqboxJiGdicCtu1y9TNrFfolGRnftkz9ZYZivs+ EY46WTlUqa7K/KwglxyMqcqueyQQL6rXKu7DwnudzEPeLuG2LsUZeV8q6PvdF8gVDEwAo671 suJwXo+4D8MI3HzAE53s41VWSZXTkXmXqEQW2sBZO5RNpkwpqPv74j7vEpU6kBg90E6/oZCP vqXDzincxbqktEMxNRb/dmdDZ2BEkY9PMTapn9wx+8RZk2gkGTpGudtSGqSuWE1DmanVkaHt le1PJNWGZyDuwzACN8Me6CRbB1xWzreSlPTi5c29QSkm+sdza4k/c2fXvZttHSdxAVB92xWF G1mfBnmEOFrEp0kz3jTXUlCoAAer2tzaJ0KuzPIJF75UnFkfn95PbLip4Hmm4j4CM3gBQaE6 a91CcpNXbfUIQPVQFGonjNUWNwfq+1h50+raJ3VSlJlBy0iBGzre/M79yYL7JHFf9GtJRb2r rvO+7E/LD9wT27QdvlBS4K6qFuOJG66V3lie4mph57E/hJ3ShTBOSr0dPFtVlb9NJSiE+H3t 4NsU9+EnPfDFwshoK3tsSOSBhk75wN5ohYbS/AlpJb+wWPLLu07XLsrLsZkiNe6kHslIro4K p1fRn0kK29IHM7Dhe3aUEsniYrw3WqChaD+8zrZlmg5VfwZx/3hCULi9Y0pAt2xSxqrauWiP EI3V/9obBcR9AAAAAAAAAAAA8Kb554j7Dzs7f6gp4hKyuQQCydHSWWeHuWM4l4DjEghwbf35 TpniwP2FVD+cR2BEJmXrrNigY5cblcglELiE7N78oi87XrgT/EVcJ9bTUVa6Bk70tARxZbnW 6ORkPVW7DYsXbdzj6Rk2TGq+LS+1zBBu5/n6GpiQxcSG+azQDAt0rSYQ+ksLPmPyn/TBCIv+ TQ2u2MNG84Mljr6BRHz55620ezD8XADfbqofKsqrcvZw2/XBNlM/Wk7+UHExC+UXprN8m0kA LT11iEId48BIZ/elDB/1BZ/8V3l78IS4DyOMOjYqKNLUIoeQ0SVXcbQjNSxOxzg9PnWwbVYD 4d1gth5Oyk3dvc7cTFJQtzePcLyt4xZf0bK+mOTl5mJuU03IYBMIXAKhOTgsxUjVaPMypUWq oagwuKlZvpDv+eKSEvvdqpr29DTx9MVXoextt+6z8ooXNUuk/IdseCjYy9/KMhkVolBoMQAT abLXyy36sx76fW7HD8QSiq+/++odMSmhPeJKtrzeB611fbkYjz3mQTau9IqK7zmCp/0zHfXT XvhiXdWRfAKXQODGJzXY7pqzzRwfGsElELiEnL7Cqp962Q9hGIHhG2R6r/PmzXpOBdFY+R6W ODvH+jgQi9tmn5YHRhi13SH+Iab6ieEZXTipz5R0WqCjo6ZOfELaUBuMwPCTHvh8Smichych TL6OaFSOs2ucgzurjfuoj/szkcgJ8I0zXmPqnQqVU66wG4WYsEi1tYHRqQJS63VuZUsAGq1h Vl+Q+3ln1z1BXQvGz2H9Lk8d9XB0VFOaZOVAyWGx2o5VOblfiKtiCmGEQR0pKeISCFxCekus m977e1F+7jUEApdA6M0nHG/rvC1eGz2cK5UpMTpmYV5+lViCYiftQqzMqit7Hk6I+7wbjLKi vRpOFg6Z4rrN6QSuq42j7j5vVCBLdo6BWNjo5uptbpVLyGTLHKaktQc4Ouy3LszO+6IbRmD4 QTc8GOQR5uQgH5x6b48wja0q65cuVrNjpGd/3cm8M7upoY/mxDouXbpyvk5NWf6F5loOyviT RcpL19lA1ZWS8xN9MMJuP11aJiQQuIRMWlyY59Itzo52+VgCl0Dg5REONrTd4PLl3X6WFBlm ut/ZxpNLyOISCFxCaLqthY2GISoi735vN9LT8T2xiOTt57FuW2x6OK+x+VIPjPD491rqBDlo 191mwfbujMrKHzjCZzNe3ogARlrySh2cQh0ccmLl5yWxBu0WsH8fLo/0UzeMwILbEPPzwhw+ gUC0NfGz2B8wUXA1f4TcMDYhxfIuNzedKCB0JRMqDXbZ2NqnRsosC061tcvXbkWIBdUo3yCP QPG7nUsgcAkppJCAaKN9+HxxuzAi6L3PpB7JKewlJGQaO/hpqqXLpju/eLSh5Q7c95vEIesz Aj5+0xJXNIacJj8WTKyBIz4iVjHJD4zwWD+WhOq/t3jOu3N2GZtXlv7xff10YZAnykjL3zWC S8BzCQRuVECcqb61iWlGVsNDAQ/pbD9blZHnaW+8Xrc4M/lYO+16L/yYzb1YU8IPs9fTsIzy DB+qI43Dfc9hGKkrILu6+Fha5xFwEwVmU1Jb/R3s9lkV5xV+NePDFpLXbElDle57Wk6BNQoF VKMyLKxTMEFsuW8w5/KLyl207Wy8unApMktWKqHCwdzTyrOhsGxcsrzbPi0pExKSyz18PDZs jc2MbBMb5+YNVDVc7+NNrbd8Dp+VZ71qs7q2+vx9+Zm4KUNgnilMS9fe6e0V1Zii0Ml0c6sQ T5/GsnaxrHy3renT0nxuchLJR2/VVtuyyCixJT+fcJDSfpM3NS/Wi+mgHCKFBqA11u/ViO4K KRgu5Iw3ihBo9AEkEOGJQmxshIOT21rHhvhaSRXcZvaxLGzYVssMdCZdXI41htDoYqW3P6Al sfkXSE7cN9Tbs0onxDSCm1gqrd2aWRkSFLElZKCYf0teu2/oGMqp42LTcgKcDP61I9YruQ1b doRAO08WIcxZi/sd7V9UlnIJqZQoF81FhmmhQdJ5IXCrqdd75NVwGh+FiraxiA2MlKxYAoFL IFDD4hLNd1j5Yb+m0xWN3fyNdFBuUuMov2gTfRszCzy+8Wmf+FXGOVecX260zNgpnJQsdaW7 3WrbisVbtMK9I44RyZfh/t9g+AqFNFJI4MbEEe23LNfxrIxPEjctKCCcoHXdFb8luLzbTTW8 7EDHbaZhzl4d1dXnOf2/9cNXKKSRKP9kq73q1sHswsqf2V0zzi7I+urLnGysi0uAfpBsUmr8 w8LUt2qvXvA/66xL3Iu+KhPeB+I+AAAAAAAAAAAAeGP8c8T98dKyevPNykoLp6m9aeFMKW2V WrZCLs62K6aWg1u4duXmtOLyc5xZN32xjkHRX71+kbSk5JZVdujia2m+XipblVdssXMN+wru mUVSCDGtJWQn812KndyxZ11MTsctPoyUZxWYqskVp92fGJ/+Iww/4cBnQ52tN62QXF+opLxZ 3XLrVk258Vr6YtgUGIEFtzsayjU01LdK7p1omkk9EumurvTJErmmVy5X8kgoPPPiHcQvgPFp bqyr0pIVcq5WrVDySCj6HJpsfKmktM5sk7LSAonldlV//9TxApTV8k2rlbajgycd7Wd/U1KQ vGn56gUStztV18fmsu70TnZ7PjUmRmOtfBi3aGonZ0jT2bcUEx3Mdkp/svIL5TbCCJ31S6zd 5iWrlJWUlJUWa2prVVPEe9VnxL1OmGunr79q2hqPn2zZYNDMIo/DMALDtxqZ/W5qG5Q/mWS2 28qtubxths1NB/0EIcZVafFyhXYNW7ol7coYDPLz3iLf9EoHd48uyfebFrqDveVyJWUlJeVP lJQN/Q+RSw5GhgesVVq2TEnDK/54SxHk52mm9PGGtZszyqrOc8Qb+X0OtqUFL9+xVepz9Sol T2zJlx3SRrkwQkA779gybQHMycYwjMBlhTpG+5QmddKza+pHpl4YISdH7ZUvTayRU5L9zSQz BmUgzFVNaZHc8v5k6ybDNnbDpM2qg2hfL/ngaFhVo8M5HrrKSguVlTRySnK+nd2kdH9VmJu4 c8kK44BBChWBacfxUS6LP1lmKP7nxBAiVNU2TRecZcuU9nknitom7VdlHIwI9VszYaZjZVlb Jf21pajGzkS2vK0DIgVUGKFB56Os1ymvVFZSUlZaoq2nW9fIfTTrbOwkho+7qUIPl2jr6RMn XHWfLchJ3PjJ8vlTx7LSydOHPZGJiDEQHuK7ZpohKyutD8WmjCqsB/hiYX658UZlpfkTz4vG Fmw+d+JLTzfrQk6QkfL6VVMdrtru7hP1DdwrPbfR/WV+TuJG5SmdXB+KTT0+pfzs8xbaF4E6 H/xn3v+uUE9Oxl149SdUnnq6l6vJRNOrnL18J3L9l6RkGOyR9SosKfV4J3yD3MZz3r1yobKy kpKy0jprG/d+uFciizPIwmDnvUoLF084XLxzmxGd13h19n27UEGt1vlk+YLJYbRBRfc1TTa+ QW7lOsl6paSspKS8REnZCD1Klaa34sMICRuyW3Xj1HlZukLN0PcEn3ZvajcYJAHGae+ShYuN 5VwpwL/aSirctXu3soJPW3Rsf/OE2ffYEIzqmqlrbPlKpf2+yWdonbOITHF8ktEOaWHVuQts zdL680QIdPgXqBitsmOT5Lrylrk7CFGMXyjirfrwDyWR+ts2rhT/umCN+oaQk8W99+T1+koc xi+9wjy42GqLspLM/3L99RbkgtFnrYob8zNDrPZvk/VBjP5eN3KaCGHMWtwvxibrqkzzAC5V UjYOOtHUPMn+NDY1QUXBcv3OzT6xCuc2pBBb3Z2N5Ja3q18Aj6Zo09VxDheos2DtSrGrXZt9 wuueEiODdu7ZoLTe3sHzANz3HIYP+bm7bJrmLbFuvZJves33LBiBYaSNdjbMbOkCcXHspQbG xg1U4fN++JCfq/NGJWUlJeVFSspb7Zjk2mszjAzM+uoWJDqNy4lXW6A8TxLnbduscn1qv4iz WbpupfJy02z38l+AuA8AAAAAAAAAAADeGP8ccf9Zb+/dLmjagn6Xurrv9cp2QAvvd3dfZU5b ChK6xZ9cCnJGTQuE91hMWUHUixDzKof/jMu+1gGNMaGr3T1P4P7fZukTEfLvdnddmjSQDmkR 0V7e7a7OqcVpf+uDn3C6r8oqQzIYY1DnFQi6LDfeK2zOAwGMwP3P+wR3OjvHJxe2hZE+waMe 9viUWnnXuPzZ12MUPub3XGMwFePMuMadJkXyMz5fYQY7Oq6zuc/4nCtM6CKj4zpnUpnWvid8 /i1oIuwTwVF0+5Tbc7NTYWFc6uy8JauyqBhnSXCEfU97ui9Ju325s/OuYBrPL+J5H/ygm3V5 ujU2xmBcglj3+iQ5YZ4LhA+75UvpTrtiXwHhY17PtRe3K+MRh30NkjdjXmWzpZ8xhPe7u6/I RsFiPxTwH/b0XGcyxpiMcTb3sZB/n82+wmBchKBbvb1P+8TiPvqMkHWF2SEL6eTp7ocRHudq x/SP6nRro/c2i6W4GplX2ewHU7+19MOIgHtDoTRx520+b/J3NaHgYU/3+CsEp7PrLqfnAZsl 9TybNO7SFXuzgzHG4jwSCCbmSPJPuSF0TLMkxM/gOJv7WDhpq7hQMilSs8td0k2skuXNks3F VU6PdHl3XZQsb+ZlFuuuoP+3me/clyAQz778vCi66nvC592EphvI5BkUPuzhXJ/+eZFUOZ70 orjDmvREQzf5ckPo63vK41xhQNOEkdlxjS3/Qn5RJ6dpF4Hhm/UtHOuN7/+/pQ6YCLh9mm3m r4TgPrv7youCw+feYnVM6tVzgfBB98TFq13sh7IRCQUPOdMs7/v9k5f3THjaK7jLmmZernLk D81IUOyV7L3BeSSQvsoky7tjunlhjrPYj/unO+ImFDwQj0jelQL9z4SC2x0d47/byadczo0O 5tSxvOCx+l340FefNUgLqxIFV6mDD2kiBDrxFBq63tB/UXr9ErH/duvoU7HUzjzxlHbkMrlP cle9cJx8+DHt+HOF2rmDN5oH71AP36H2yZyPEYWXyQN3aSd/YyqK++1HrlD65cwEY0TB5YZD d9teZee+wjJTCM6UGrkwAsOPudybHYqv7g7oek/vb/1Ts1QJ7iku72tszuS3d1/fUx7nsvQP 7sUO6HqP4DdBz/WOjosM6Gq3ZHk/ZE/6ayVtGmJc5/U+FT+tQuGTnq6xKS+3h+zuiXuh7vuC 3hk/DqyvbkGix+1DNykTcb5EHrjdfOxJ68AYWThGGrjdNPwUiPsAAAAAAAAAAADgjfHPEfcB AMBbZVIKfgDgbwbn24KCtB1z391s2lRacY3/ppsD/GnhXLgwOff9n49XyLkPmArrq1sziTYQ 9wEAAAAAAAAAAMAbA4j7AADgzdILIw0lrVEeDqoa2pv3hPl4ZvqEsGomVcEFAP7isFuPxGKs ly3QDkw8NassLoC/G0Dc/+cAxH0AAAAAAAAAAADwtgHiPgAAeLPwYKQsOc3GwlJdXYpJYba0 gi4A8Pegs+V4alS0qXVjA/US7213BvA2AeL+Pwcg7gMAAAAAAAAAAIC3DRD3AQAAAAAAAF4T QNz/5wDEfQAAAAAAAAAAAPC2AeI+AAAAAAAAwGsCiPv/HIC4DwAAAAAAAAAAAN42QNwHAAAA AAAAeE0Acf+fAxD3AQAAAAAAAAAAwNvm/1Dc7x//sWfsewAAAAAAAIC/K6yvZyT4vl26vrv6 VoIjuHf8rQvZrxHela96xn54KdzLX/f/9vZ7C8R9AAAAAAAAAADg78j/objfc+bt/98sAAAA AAAAAOCtAE4M/DkB4j4AAAAAAAAAAPCXBYj7AAAAAAAAAIA3DxD3/5wAcR8AAAAAAAAAAPjL AsR9AAAAAAAAAMCbB4j7f06AuA8AAAAAAAAAAPxlAeI+AAAAAAAAAODNA8T9PydA3AcAAAAA AAAAAP6yAHEfAPhL0HemrIrhHc/NH3rU/NY7AwAAAIC3BH3wGqm+Dp3BS6P/TH1NPoltvUl5 VFTld4wTz99o54G4/+cEiPsAAAAAAAAAAMBfln+SuN926FJ1EzelgottOFsu+JXadzanjJtc xk1rPV994KGi8W3Zr9gyLrbsEK75u3oRwpjObfuB81WtMFZiOZjfNUZ5QQcoXcfziFxsGRdb LsDWfVl94G77Ww2IPLSjV8jMgdQKHrbm0+KeX8nwD8V13ORyLrbhqwrB7bfevb8fLfzPCilC bBkXW9aLLTteBt96iWRPa41zt/toMRp94Hb92+78n5XnkOh2LW0QX8VNaxAV9SH0E2+9SwDA Xwna4Uv19IHkci6W8k1V39032NbQtWb2SHI5D1t7upR/vfVtD/yvRVvftwWobSt3YGxwwzWv yWdeapiRnvZyNx5t9Nkb7TwQ9/+cAHEfAAAAAAAAAAD4y/JPEveJLT1orX9/8O47/7Mz0SWP kVeasPtf7/znnXcWmlYFEsflLB+3HT2WkR21+yPlBfOV5y5QnjNHZaNOemj/rcYTzyfr+yN3 KyvKPE23zF2gPHeB8tx5BppBbcmHH9BFCFPOjHniGf3oteRgx/1bPp67QHnux2vmbojwqvys avjJq4/oxKP2wZsNwkskCVcoB++2TbT7jH7sXhN8idQn/nW8YeB2y8gz2tFrFHicJLxE6rtC HrjbfuK52L6p40Cax4YP//ff73zibprESKktt1jxznv/eud/dmJd8798s1Nz8jk0erfpyP3W PxKNSYw+aB+60zj4hHHyt7e76l5EdW6spfamuQs+njNP+T//Y2Fffbrk929hdiSh/JZtiQ8b uEN+253/s/IIEn0Z6Wa+c/EHn+xyNipBWkbeepcAgL8SVKYwyXvPwvkf/Uc106/06zfYFu9Y eaLDxwvn/Gepn03W0OtSqP9k/AaJnrQeut06/JD2Wj23wT8UR+pu00pwyT9Z95p8FuKTbaxt twTAtONg5/4/ESDuAwAAAAAAAAAAf1n+SeI+FYKTnFZ+9P6/5xmU+NWMltYWmSx+571/vbPW ozuSJr9V7VhCtK+2ir1u+lgZZ4woGCvIy3cz1Px4Y0xo/63Jm6Ybyz2C0jWCuomCMaJgjNhY 6+WfYeDbUSZC6HJmtCOXyxJs9QOqfIpOEQVjRPZZYqa/umeV9x9RT/qO4lODNixcvGDhYqWF i5UW6uyyrkwWIW0Sg/EKMtFh++JPlMW/bt1kkOzbfDkv1lZ1xzqlhYuVlmut0K/GHbwn3jDO 4I1UxxrO+eDdd7bGOuV8Wk3t8FV75/3/vDPPsNS/9tc3OzUjt6COCmtMa1jZ69OSIFYWLkcd +3Xj4NO3u+peBH3oJvXARaLgZFFTkfocZ6+Xivuj99sOXyf13Wyd+oUJIEEspV3JTAhzdADi PgAwaxijD9v6z9bXxKo51YW8UXH/+CP6gW/qa2L37se6/m3F/YeQ6Itwx9TgAjjvtXpmnnhK O3KZDN9sGnpMf00+aYO3qANXyYcfMt/wF3Eg7v85AeI+AAAAAAAAAADwl+UfJe53DKS6rf3o /X+vdGaEtdysaaR57PrX+//5RCUcTuZOmNUT8R6BEXpB7AIhQjuOQCKkDT6fm11oqb7TpOxy 8YDM8hEkOhaNyfGKZiZ2XZVcHPy5qoIYlVDqSkWaZcLi4M+U9kYTR1xo6SlJ/p/jjyHhqYS4 XHQ2P0P4SsNhMCLQAerGASYJnJgiTmIJJzE+09PBdqOZv2PFjcoBBBI9bIa/zyuiOKjN22WT YZMg87hwXgAAIABJREFUSKecKR+428hqddHbtm672W6f9hTKdw0jTyXSAH+0LsF0zgfvfqhT 4Fv5E4UuiLX55IP3/rXSBQpvffgqPZw5Izcheo6BFxGV/8Vr80lrS01O2hL5OeXo6zsN8Eb4 mdxD0pnr4vNScR8wYwpxWA8XIO4DAK/E8BWoPVPLjRT2RsV9EQINX4baMzV1Utz+tuL+A0h0 Cm0S7o/jZr/9zvxZAOL+nxMg7gMAAAAAAAAAAH9Z/knifht7sACjPvcD5R0YYWI3QqYJIs2U P3hP3QA3lH1kwqyRxkmvhbG06/L3kmmCeOetmpnjeb3SiyfuQv0k10AKJu9Mo3xD3Wx8dq5q xNcTsjL8Gbk0Zk/QCKFTIXl9YwkhKLXBvf76zIcAiRDo+EOofxCLirJyjLFM78H1Ie3ixOJ9 Z8qKs21sTbcaNUa1XRRnbmk98EuctbJxND+agUCi261HRhJiYu1csQ5xPZMGCPWfIhLcl3z4 vyvtW0Oa7rSxj+QHqX30/qKdIf1Y9ivH/HpVU09MLM4FI6YstICZUD8QkjVcM/S4XYRAR36o okL+6GRXZ8PVO6xVjMOkljgXTFloxcmig/LexomdfREYnJvMJrzaJ2u4SuxKzMg9qIMdkVzs 4uSoo631sUaYXUCm1GGpV1yPtBrtHTL7WHICzj0YF1J7rrQfgUQIbfBWaXEROhrngikKxPUS +hGafMb2kXtQR3dEcrHEW1iRS7YoPY+YThzEc185PshLxX368G0yuSE4Plc8hOkL6g6czi5t 9MGUesez84cu4EspIZETnazquzPJZzN7hJBfKhdqnE8ahO1E2o+/qUdPwpHvKylMfwzOVdZ0 TIN/+TdtIxOnK2hHb5QWFaKicN44QQrl80Zqq1d4tgsG54IpCsQLsydNiugpJBovKGmQjBeT 7YKpimv5OSHp1cV9Eg1OScPJBUfS7ium7x++3NTJx4TnuGNw3jhBCvNG+9HrpUUFqCipZ3jC cxPvy2w8zj1E1nSeZ2xrKvdR47GpkTxX0cCYiGRUczC+O7euCV13oe7gI0h0qZbZG47JdsVU xbX+kkOBk+VGhCoczuZNcThyB4JYYUlFsqZdMLSMnvGGiThfKigmB0fifNM7E2m36ogkjGRN lvkk8guOPWmZMvbm7iF83sQy88axwosHMrLaMniPqbJ5OXYHglhh2CL51ehb9GkBb5bZ3ocv UTt5QWHZ7hhqXBEjuYLsgslzwdAzei4X0/qT03CyfzbI3VVFbIpMkJ/rsvDq0yWHpvp/BIm+ zMiq8Z8IDj2DyIisORxH/XlSNxo7xN0Qv6BqfdIEBbW1EXWfF/LuTZhxBlKzq+SH7I3vS4Nu Tju0qjqqtJN5Lhh6Jvfr7IauqBicW1RFQM0F4qHHkAiBhi41dvDQoQT3iXdjqUvO6Rr43u8F 7YXBlIn7x0mso9h4nGuw2G1dSNFIxeTaM08g0aX8onpM5MRw/Io/LeRPafrQTw2UFvdQgsQs thFVNERrSZ8Q90fvQX2H41LKPDE4F0y+Vzwtjf+EOoJAoovVdF64ZLWXh1d/VjrNHP0+DyHR l+mZ1dIZzHbBVMe3DyVWHsusPdsgn0Pv4I8NlBa3ELxsSfgmCQpHn0lLAtxvGTibmZztG4ZD Fx/PbPm6tKxCalwXWjxaMeHqVn3nEWx8umtw8J616rv1PQ3lp5sApytOd2PPaQIO5xYss8n3 TqCl8Z82TXmD1bcJklKlZnHd0xTUHbpIgbioELw7hprQdDKv8zA2XvqiSGYnNP2i6PB+y8DZ zCSCb5jY4fQFdSmtnbGpBS5xVHTZKYbgYFyyeI5wnnHEKPqzhsHJnWxiHcnKKZGOpTyi9nNC +2k8DucajHPJOlwuGpqV6Mwbo5B7Qv3wvj44HzGo8qjUM32s+29fEP87AcR9AAAAAAAAAADg L8s/SdyHhJ/WZ7p9MkddP/UobkC8kX/bh0quDpWnyl9y720iozfCx8ej6kbFAenFY7cgaqpD LDu87qKCsQDOwBM2GrdUDdwXb4qn9wxXp7rpEq5PfBgQU0/wiijQS53ddnXG8PXmmmg9nSjr BLh40q+DFxoaa3RWG9jlDYs/V0yI+y1XGtgHknKSDffZ2aWexE3Vowe/JTckb5+7aC9KGM8S b+S3mvPBXt30IfzBWXRPynNIdLuO3hEWEq6vZakiwUrb2l7d3H/VnoKMgbtNIgQaOFVYlGug aaq6e+OCpduXb9JRmTD2tU2adKzhfDmV7KhluXfCxkXdJMkrfzC/X1qN9tgtiFLq5OKpsnvX urVrP1yls2OfhdTYW9O6Mvnw/UYRAomu1bSzAq2Mtq+etxvTH8NEIBHSfvgyIcbdzNxy80aN XfrhngykdVTa9PCNNtbB1HC0jpnddi1LFS3L3Tr2m81TDfeu1fPI8SD/kWX5MnH/6LXqvFgr W0cVLe2Nm/cvXYwOmlpQVwAnxIWrbdVdudTarqTQysVHW8tSRctkp6bhErWowOJTNQNyZy8O fEvIybe3sZILtaGaRaBxZH8K/Wrj4Js86DDwaX5hjoGW5R5p0zv1vfY4FcVUnak5eE/8habt 4CV8tJupxvr1mt4azrkRfh47dK12almq7NZR1QsyzjxTMfxU+i3nQfvgtwVVte4O3lpya8wA VWdp7WRs8YriflVtI9rDUi44VvtsIu3SBgg9T5qmiuwv5eiPZGqNpaG9+rb1603CdWJ4WTkt bjZGmnqmKmrG6taJtuXjrSPPIRHSBn+fW1RlZ6ajqi1bsZZ7jTxMozqx7Vfrj8o/qhcqaxvR fv5ynfTW1LU3MVNd7nckm30HEn1fQqqzVTNZ+/FmneA6W3SSubG+1FJPwyHNPmUogzFOl2bW ph0ZJ7VwkkP8tU3tdojN9tuo7Pa0wrYnQBeIQwgkegKJfkiNiTbZu2mLmrkqqsvbzUHH0FJF y3LnbrMdO90tK04XSmdQTAvvdHpGlp38MrP036vvrrXF1LbhbpV4OCO3W3uGcaGBOia2O7Tk Ym6f6ZZ1sIAzm6+eR8+TGivN9fXXLtq3V9NKz9Vlyz4rlU22Jgkk+5BYM2OD3eoWm1cYmecP EwYeQSKEMXK/qesIJsBb38BYfq51PHJ8Cj8t7kMYE99y7rcNns2vzLY1c1NXlwuOvf56q3jN mKGJPgxfJrX3xIUGq+laSx26qun4WRmt3ODRHNIgV9alvRmDRqnID9kyxjKWlckYp0/oqo/b By+Wk3sDvd0lnRS3m1Rsbm+psn7NSu0Ag/SzFX0PINEtSmdfSmiwmo6sXctdOo6bzdNROUdf pVatRNzPcw0vjY7BGsse2F02WlZp7vVf1Bx/1i4LztGv8iuqXO28tBRn0B13SH4G2/q/q6gi h/q6b9Wx2qVlqaJluUPfZ69dUnyM6xaVGGexuD9yE2K3e9nor/l4+bxFqttss4I7HpOHEUh0 rqiuyFJly/x/fbRovb1J0gF8/2yGM3S1mX0wuRxnYeIqmUEtSxUtK8OgUFVDrLkPVCr9XNHW /11FJSnU132rtqSTKhr2GnoRjsUwjnez8RgCie5QBYMRLnYam5dsNYnR9at2c7Tao22pomW5 bYupmkWKZ/N5yonndBECia5UUWn+Nuaq2torFq5atmHvRrn4aAVSFNaDCCHR4Vh/S1XtCRs1 Yx/TGHYy/Tr5qMJwKqqIAW6WKvuNVHatV1obZD+1oO6Rc8SGclNd3TULDfZ7RtklJhpJn/21 Gl46AS25nDtypWhuUwWD4c62uvqWKru2r9xlNW1BXWJlgaeD3hoVk+X6aWkxEUZmjipalioa Wrs19LZ7wsnMW/IfIBs6BrFYrK217Nm30vUqtfbCmu35SGmj+RZPGu7QgVmJzpxz5aWVZvus 1dUtxezZ56xlmIFPG6LRb/S+dU38bwMQ9wEAAAAAAAAAgL8s/yhx//B3DUS86hqUd83pUhHS 1DWYiTZYqpqJoZz73Qqlj9uOjmTWUg1d+NRDciLp0HWo0M8wpH1ySnoBnJGasn5XXgZ8p0mE QCKE2jGQidbZn34xl6+4Ia6e4Oifuif08KxGQTt8sSBEXTOQiqofn/pr68AvCXZLjSK5UbRn kEzcD2MGF7BiMB4rFhrbEa9WHJnW81ijoMl8rbFD2jF8PwIJPq1P91u+3M+l9kzZq0T7MSQ6 E2qvbeiU49kguzgcF+63a+l++Vz/kOgPpOURnKhNcf94jrVtuaho0sbqGaTloR0aKwpVt0o5 Khb3ZRQRylB+iuI+71htkvNHm1NQDd+RJbMwXhpnobJt9Wb7cn+qbCB3mw9eIU2UOFaAfOhe 68hk0WQ2aXlOZxcWaC1Gh0wV90UIJPq1uKrGYuXqFesW7o06iO1EINEtqkDoq7Fkq10Num4M EiGQ6DkkethSnuUQgNdLHJW791IZsdph7/b1nvysrhuvK4PzTGjqPJDirzlndQyK8p3CoOoy vKy0FqwxW2pUiz/8oEWEQEwo3sddeWUgqv9O/UkEEiGM0e/rmPnai1dphxxJYolvvAeJuF5G Wmv++/6iHa8rLc8XOYXxmovX7Um+Uij8A3Um6zI8wwPW6DnuXaayKehYPvcuJDyYUVC1z0fY PPQYOn6/sqzIPzB4X/I3zcOyRfILuafOZMWyfQHCOLpcZu2uBi9rtLpZaZIIkVTpZDAT/E0X rFTZIPYsQiAR0iz8KcZ0p57ejq2u+U7FF6Q+f8jARuioGq10pNcffkw/iUDHH5FbuiOdNRfs xoW1/ijZ2H7sBsQsMVcz1nSvD2NOlAevq8wPsNi8aL3eRxY0XMdlSIRQof4kP905a2PR1HPy M1iR7qNrH6EVe0x2pTg3y37fuiWb3Zyp92qOIpDoGb1PVJqftEk1J6btJ/kN9bhwe01TP/2Y Qy2jCPPkzIP8EBKdxlhobNlopR7ELj8yxij03LZ2+cdaWMeSC+0HfiwJVVULaAsmj0MnnrQK v8oK1NQOZkY1X5HzcCQK7aqt4W9WcK959DfpFuwfiazK/e/vsko/ToDFwbkGMYvNNPYs2RNq knxi4nY+HxsWvnFNZPjRB5I/KPyRiiRn5U+WrnZpU2xoMkUErKWR3jLHburwE0m7x8fJnTS7 bUt3ebRK7j12DWIWm6oarVq0ZbtVvA8kObNFGzqWnpmtvy05ZuiRLIztB34qiTLYoYGxyTxa Jn0K6EM3qQfGX/SCohx9LDm7Ixb3HV23rNmxXzPUrlp6pofeHuvtsXxzmJ/gFnH0GSRC6CPf VjZn7VuwTDt8JLV7YjhZYbYaxj66UXDTMfEMPqoqznW1tFltRsoblhzyoDKFWC+VhfPe//cS X2v5tDzsFm+rwP2WBTGDT+lSDZox+m1Va77qR2q2uNO5B14Yxul4RuuC80Os5i7SNMk+kye5 9zYk6nbTUV2x2GqvTNw/fr+iEO9kabPajJQ/8lRyEuXg51Ul2K0LdxtihzL5j2VHFspT3M00 ty7Y6b0xAG4ffQaJEGJNsaet9XKtEvyxJ3Inq145Lc9PdVC53tz/VUUfTeyY+lcDgYbHobb0 /dop7lPF/Yl2zXevWbLJMsyhRnw86FxqlK++joNKzOfTl8xtqQ8NjZpW3IdECMTriY/xWLJ4 98q5vn7N56pECHTwTEVRwsYPNxtlnCL0IZAIgU4+g0bvxHvrq5qGmqeJpPceCvcPUlm0ctWO 7aq4x+UH/nhanq6O7zIC1d7bgonHDkNvXRP/2wDEfQAAAAAAAAAA4C/LP0rcP/GEcex2g/B6 8/BjmghhjD5qP3yZBN9qOfbkdyuUHkuIjjbSjnRtfNA8Ildobug6VOin6lLqmv+lgv104n56 wL4N6KNZLIW0PK8m7rcO/JJot9QosieKNs3/gdMOXywInpD+JeK+kfGarWofLtw2bwcOK7jd OH2CkWeM4/eofVeaBh+1n0Cg448Zg9dJwutNx16tXp9Y3Hey9a8O7ZJdfNR65HqDcJx04G77 iecTmRBeWdw/fqWR3WW/Rd0uazBr0l7O1y7up7p/ZEDCtv4qXirME89oR6809F8kH7wzUVyB UuJhraUkqW88mTVOjeGNl6d04zWK+0UWG5ascIGS6VfbRhFI9JwxPN5MStLxIKILv4JEiFj7 9nbO8cUKC48+kp96+rG79R1fhlgGRdM+f9kpltcJY/SHWnqZ+jx330nfkOoy7HWt1+jiww7c bT7xG1OEQKP3K2s6/cxMnZpuifd9N3X2Z0VaaiZ8g+9+1CaZqeeQ6EHzgdFolIuBzusS9580 tHfHue9fgxrJZs8yV4ziiGwNdJZphLvXj9cefEQ7/hw6/rB96A7l0EPmyd8gDi0gptwqoo9y 9IlcNcunjOPXG4UHAgKro0pHamWuuhq8PLC6bm1Fsqrdo/fbDl+pF46TDz+SyXbNwnMxpkqr 9GJcckRNQ7LER0/bj94oKmf429h5tNytOYpAwoNpqZm79xMSe66QR55K3oQnn0Ojd6hNla6e 6UaB7HLp1ua6ynwPC70Fe7Pj+Tcoo88gEcIYHScyO603ugdRFVZORbqPhV+mefY52RXa0K0m +GJ937Wmkef0EwgkulhaQ/PUD0P1jNfK2hUhkAhpP3K1pIAYlVSFZklzjs0Isbgf4hHflnL4 AX34CrMlTUs7yjaxv2T4KfPwr7RsJ+2QzmDyOHToy9r6gq1mdenNFxS/tz1qPfwFvozu6lFf MPxYmmjoRyKrbv/7dt41n5eIO3PyGTR6hwqP1/ffaDz6eOJ2Ph8bn7RFvQg3KE2cdfwR/ejV esEY6eC0H/YmoLG7YqPiNmtV5g49krTLG6omhG7w5qYzLkvuPfkMGr3T2FTuaGi2XWtC3C/O LQ3CJHo23Go6/pssjOKCqw1FSUGEHlSL5GIVIcxMc/OLXlB7I0fSxAK9WNzfpqPuXBXafoM6 LP3EMnK/lcHDRfnOs4UIrKuQCKltZIY47VFP+D6bI3sGJTOYiY1w8QxyqBF/GDgSHlns6EnF D9xtOyn5asIYfdjGO1WfbLN2T6SCuD96j4CNtLJy0Ej7tm1UspipTF4iyui/mtVptIu02SXI Gisub/HUCwno+bVy6LH03ueQ6EHTgQ5fvxw7mbjPbvXxTjHyasIP3G2XdhI68YR+8By5OkHL CO+dd7JO6rY8xV1L036Hewvh8EPxLnjG8DfZOTW2WjFRxx5TJlp/ZXH/aYvwDM5z854AKIJ6 dRqDGYn7u3frh1riP2+SzODTNhYjEktQ8RBML9+/VNzHeKxZbmFRNl526AldhEAnHrdwP83w 2GqadipZ/Fd++DLEKNRzqQjKF1EHZY/Gw9bDhxLifFWWbFfNei3ifl/fNSqnXn1zYHhEb9Nb 18T/NgBxHwAAAAAAAAAA+MvyjxL3Z80jSHQsOjjKzi3Hu+BMxRHFvNtD16FCPxWnIpe8zxXu mk7cTwvYty5gILPzloLlq4n7Cmn0J0M7fKk4THN/ACWw7qLMeOtOaw2vsiBcbYSfzy59jFvZ F0WvkmlnVjyHRLdraVRUIHr/Xus9OhK0/evQ9ZcmG89Y3G9gjWDR1vv1ZQ7NdqlrLv1os37S 0cl1iV+vuD90vRmC0b6uesaypp326GT9f/beOy6qK///3/19dje73xQTYwxoEntXrIgFREUp AtJ77733MvQuvfc+lAsCQ++9ytiVofdeLghYAOH+/ph2Z8QEjFlj9jwfr3+YOXPOeZ97Zkxe 99z3Wzu5OxTdZ3m7b0K5uQ9uXdkk9YaUv1ua+COa+1FCp26Lxg8EUlLrNMFQqss1mQg1z2cQ HoGa56BcPy4W9oMHLp24Qr0oRJ2+wLV3+0+sZlXW7yZk/2iaDkm+qyrIz8JOGffGSebzW//B LxbyiCb8MDspZTs2w7pIVILvkOhCbX4OkejZwBoEwk8HhMfJX+O4FTTrT7+ZF1xtDUUFP9Tc x1U42RijV+bUWZZDBw/skKt2zn6x6d5QEUkqWbLqlQfWIGnvnkaPcRPmvbl9z+Wz9NeF9+wV 9l2/sF/VSLUuITeu7Q/0DVaSkDhGbSbLpRZtmk9TkCChuMuI62sWlTTdBPqiC1HJ+RYKN695 LfiWIRCUamlhfVyhMrxhmf42Xm2ToYaLsHQwhnwXISzQQ11F5bxJd0TjW3LjmejcUrHD4upx j31Rn03Mf2BubsHDyUGNhcdWFFMbSr2gz1w8bS9+t3vf5Vsn39mNTMdPHWWVY3MaIOYs2piI 5r6BIibbGY9AjVMQ1uHKVWtxTG0wHoFqRiB3ySvadzWjxqHChgAb8S2M5w6f5XxnwW8ePcm+ 76isfNqr8AZity+TK594mBtz84qhWwo4PXEtoJ1Aw3hkXIahgvQJ9tunSc0kWAUctKDXUQ10 U31oi3HgRY/LwrL/2PWfLvk61ZHM/aiETBPpS6csRu4Ur9B8trbBQEmNk5ti7g9jjDSvH9/3 01n+M2z0y3j2xIHdV8247NtIFyXvvkdU4ft+oJwypyOJGWCI5v4F9dtmJZ71tDOvfx4c63WU yd0yeSAOP+UTkCB9VVI253XYOxmr4sJ89fSNL9gOJDevQlhvESVnDp3yBHR2ezwC1Y1B0cbM ly1EaQvqxiXHaSkoHb3kbduwFI9HIHyXh7fHLaabFx27/cre0A30GyqvtbF2vXDZ1a5xOZ7+ 3cmQu91+0AhpVtFOElq+vLYP6SfZMg9VF0rdMFJwLPEkv+hvLSWgckfYawTVeNDTO06MVV+v cQn1GMqGzf2SxyFeNizXBCjX7syF60d/+fpn4YT1bglv0NyXEjaINy16SX09P9fUzuvM++z7 3zT3LWxOcoZ4l68kkauzJBe3e6oe57Z9QHx2ClveHWR545x8sl4k7eOM+Flvf18x1hPMH3Zy /0V8aq3ObYGLbPwXLhDFffrCma1f8SjrFsR9ck/8LyNg7gMBAQEBAQEBAQF9tgLm/vvUOJWY k69lYMAn4aLg0uxV8U6DXzH3HRwOskf6VJCSUP+KuS+t5cpq/mBTE0uuHLGXPcKula4VT+/Z Ed91kD3CrpVGfJdo7p/hdZX264mtHoqPiZaRlLgi7Kfk/2w9R+Cjq/dOaIq6KkaELF5pYx5l T0U/QmIjyrHamLkfmVZpbGh8+Ya4kJIVuUOz29Jyx7Yfv2n9B5v7eCStYT4yMkLD2Jk0tLK1 iLA6t5K7cgDe+3fdKfmI5n6S6Dk1nUrUu3TmfhMMpThfY+E7eVmeG3VR0NII6fLZVD7rTWgm MDZJXVXj4g1NISUb8oj6fBJCv3whKPGOuS9nFMjj0oPugdbcH/YOCBE6xSEUSfyTRl6OH1pQ F1dla2TJe1vhkipGiLwmt4Wl2M4f+0m+5nea+7JGQbdce9Z/NxRzm1/wp/OK614UEVVvLbpt VvzQ2z8c1cDwtrw+j0KQXtJrSoZuornPYVxhCtEPF5uaj1G/edFp4U4JAmHjLS2tmQyfJTa+ 6+h1WOl5SEt7m5Pz/4QFeujqGd30RX811jf3ITwSgS22tEJFIWV4W9JW0LzAg1R9976jqxXz N+fOy1vyrRe1pFmiTuzE+vlD1teGzf3cGn8zwS/2C10RMV5vtV2kDBOs85aoacSbF6HiShMr bylSAysRVXUucWtRy3eq4Fb1RUfHSWjYk7syFVLS4hB1UAvq9yclhHkD4Z/Z2RsLCGuz86MX R+oSu9DuS77OZHM/OCJJ7dYhFoeFd76PHZa6hkK3KeZ+h6Wu2vVTF5lEMEIq620e8wzj2IEN ryEC4cnmPru1pEN9MP27vaHZMRcP2Jgm9kbhB7184sUu6+o2vFknr11StLmF7WmT58lNq1Cw 1S05ezbjhncGmoCw9tSCuhRVd7jYu3Kc5boR1BtYtQQV55uZmxy9YGeJexO32W90Qb6ZifXx y36u69V8plGwlYRh2G2PvnfeegXhH6hx6aENen9rKSmzRIVYdLPfYe4X3fdychfklmBRsaV8 FwRldDhOb98nnvg7zP13xv2d5r6d11mpAvS7dOY+8c8zyml6cfRzDgqLU+E7cd5p8+b+XFxM oa6qxrXLqjKilrKyGFlZjKysmaCs0C/bBFWBuQ/MfSAgICAgICAgICAgYO6/R41T0WlFFnq6 l65pSPs8XsfZxyNQ4ywUa8HG7yiGaUQ9ho9g72ZZ2dmdVGyMqSY9lp6Iq3c14jsglG6ZMo6u ORlzx0bROEDIb3RTc0utnQzGCLEKe0p7Pouhe7cBjkstEr94mNu63DIPgd495t+8COVCMlzy 3GpRBoWL//2FDY4IlhXn38Ue4V35Mpny+obM/SknO0c+TlEWs6ZY6vP+cFxRieQJZiG7j2ju L7rZechL0Zv79GpehHLTpDl52KT8lZN+z0r+F8395hcQLpKfU1/EJM+jfuMz/EiqazY20L9+ U0v4Tj/KRx6IzIlg+0ZMftPm/nRAeJz81XVP7i+62hqKfdDJ/WgPMxF+9Uuqd10pGW/wSGxa obUy227l2j/Q3E/xE5e3YVPORT+psBl1+wS5Cp4+d1iH4J5POtpMNPfZtHMNU+gPO1NO7vv8 +sn9uiZDTRcR2pP7Gzf36ZVTZq2jdeSYmNTdxdBGBMJ3u3sH8BwTkyH9+fu1YXO/9F6Qp/72 M17myYO/YfiuryUI32OjIXzllimP9QP6g940Go/Jxcow7Totn6ufuADhEah5GioK4L0ucEM5 zTQD1bKgwMLM+hjK3I+MzzCWvnjKcpT+5H5dI93JfUcLCzFRA6GIeWzL2uZjWU+kk/saAmal Xu+e3I/zOsrkRnNyH7feyf1wPz19kws2qJP7uhXrndw3Yb5sIUZn7uORyKQsA6mLP99MtM7s Cwr0UFTQOqJx79dTG62v8jJLC6tTp23MSpdjW3615SZP7n9Ecz8uLFhTUuYIb4Rt0wrl8YLk kg4vtRNnlVM/I3MfW94dZHHjnHyyXhT9yX2fDz25n//U0saJ+5yAgmlHScZr8utwclkK22Ey ukIuAAAgAElEQVRlHWDuA3MfCAgICAgICAgICAiY++up5VVSVr6FnsHRA4Y6pXMkq7RlOa1+ NqZ2CUs9SfoKwhco3NQR0UyxblihfDYowE9bW58rAImjpGKo7oyKcDl12lQt5HkI0RRrXYUa 5iw1tOVNI41yNzm95hdQRgD/RQVOlVjzijlqzcnmV9jMUk8d3q3b5UWCSRnM183hE+yuJ6Js w2n7LPnXbKnfp9ZVqGEutnoxsYHGW09rvOfo7sLys45e6Vwk5XWiuS/hr+B8P5nsv6TWz8VX TEZXvCAHWKln5MUvFOvRjKQQ4733BlvXH5iSJnjk7G3Meua+uelh9ebwWlIVxLSm10mVY5El cEIjycRMqRr11bvMY1qql/wmlTjn5oX4ihYjTX1eLrS5/za18WVCxUwCKVc4UWsQ/rW3lRK/ ogOvR//vWKv/ormPX4LwzwwkZISVAzSxL2irlb5Na1mMKx2Pq6HJnQ3hkbTGxcSqicji8chi 6tJ9iLJi5XS8ubQqsJRd1/wquebxnXhvlq9E5TZt7iNxGaUOeryXzXtccimptNcg/HJS9T1j dYkPy7mPUZOTMQ7TuYvKUF83GxKJNZC+uFvpjzT38bWGqja8nK66ZXPx91ap/n7rKtS8EFc+ HVfzkvLVwNbOJNQu0Ib2NjW74o6J+Dc8qfbpJCuQmHP/pKiXYmB3QgPVIE5rXPQPzVQVEpZO XCTl3Le2P33Z1apkPpb647YK4V8nJAZLyWBuKGejc+5vwNxfhfCvEyrmEupep6BjbHkTGJag cPM4q9sL3zIEwiNh8ZnaIicvmHW54JawNLtuBVs3G1cxE1u3gqpA8JvasLmPH4zMjrvxg6i0 T6P7O5PE1s7GlM0kNK2lkuo2v8bWzkTXLtE9Q4BNCZSQsrqucJeyOCn1LxJrZsklZElLkVbV m2gneFQkWNG/E8IjUPUQ5C55WS1NI2KE8lVKrZ+NS8Pq6hgfQZn7xJz7B+QKHDJgLLqkRGKg GG3O/YhQP1V1tTM6dWGVr+knWTsdWzmLyn6+MVFy7ouH6qbOo/6JeZmcXuBkqLDldjo5536a lug5FrMRz6IV9C9Dav2so6WBuLSaECnnfrWuvreIbIJzDSlDPYRHoJal1OKnkda399Pl3Ceq 8kmQj+2hr26JBySKqUjd4FS9HUKu67s5PXZ2xVzbe4vHf9yvimaSUON8fOV0dOV8EjHAnEQ5 Oeub8smudStp6LoXtX1xoeZsNxzpcu5vxtxXl7O5a08plN3yMrFqOrocpmxvd1tHJRUTWexK 6j3iuG9TGhaioAaMzJFTCimfkbkPNUxAaZ7s4oGadx6iCoOvYGtrLcw/MOc+NlfByF2CP6ug eLWU+Erxm/zc3uD0UJYDCtrA3AfmPhAQEBAQEBAQEBAQMPfXUy6kJat3mcNJp2Q2lmK0FT+M 9tA7Z9CEMvjWIPyrBD9HBaNAXs8+ymfV1WyviUe7NJA9aDwC3VvGlnc7ql0TxNSYZiIQHoHq Z6AAw0viHhKu+KTNGhbEWpe+dsI3OPdds1TOQBKJ1k9GtrXKzW0Me47rEpzySFVw1zX3U+sL dFStODn9rPAIdlNDb1z1M5C/AZtCuKIfAf16ZGSosqzoj7dSQ6teUR1Morl/huuyVLRJHunF YHcTPnbWw9etVDKJTmKlnqom+3lDxUxyvCU1DpbK+7du//IfB1jN1zH3TWVFt+w20C57QbyL EJ5UoMm1l4FRVjL8CfHOR3rdZIqb1Jlr5rcwDSF4BGqagyB//ivMP375y67zaHN/zD8yUfqK iHTsbBA1A8xLCJ8ve5X/hkSIVubKJlaGXv9Nc38Nwi8nYUPlBMXPXLdVzUSSqXtvOLoginvP /qva1RZ3aXqOjAhTETj93ba9322TlYp49uHldrNi5QQ1Wbj8bMg5XqD0DAtVri3fMf7r77zC mzf305q7w9K9WXdwCNq1upQR2yxB+OcGUlxMDP/5kenDzH1ODjGT216UNCa9dpb6V/dt3fLD L4yyvzfn/q+a+2+SYqJ1xcQYmSz0ql9SzcFGGIJ8eS4Jcqhizci1EBz1RSUNQtQS0B8f9Q32 FmU+csZizKuI5KklFPcbcZ08eZxhD5+1mA81MUtkeKiGhuY5vYbI2pXUewjU8joyMctIjvOo Tot7HqVi8AKEz5W5KsgpFaGd9iqVfD9mY+b+PITPleEwk7UsckPHWFxhY2h0fK+KaulixD0E wiOpTZ1BSU6Xf9zNptNgnYUOp8fOXI/7pvRl6/b1kgW9Txs391fSqnpirSVOnpC7aV3sTjPJ cltTvZNHpSQSXobWIRAeiYNKMboiJ3RbPfNpyik7avNcFzHmdeqgLI63m72yirZQCIK6UTEb k5srd+q7i5rlJmnLEJ5k7h9jNRdwpFZIDnLW4b6496sfzvyIyrkPtYxHZWAFTvzEYdxok01Z WJz0ldvHth89wUc199MaO1w9HW6eOnNE655XPs1TRI66Qmy3dbltWje3V4nmvojE0b0cN7ic 1O+SazmkppjIy/xyVEehcDa8+S2ER1Ib2wPi71zcpqIa0x6I6iHIWYdDRJ/doJRcyvVNoLeb hLjsIeWypCbyr2V+o7+5yI9bv/zHDoV1zP17y7E5rZrs3505c/z7g+LnZBLdG9YrVvHbWsJm FrmqCXz1vZJ0fCd6klCkmzAX37FbLhp3kdR7CNS86O/pJKekc9m2A3ULfyAsI/zG9rPcFvX2 BdTa8ps098+d57UR9RskvZiTqCjKfZhZ7gqGNJC7rYGggBCLVQeWVEB4xDvAh+/I9m+//MeP t+M+J3O/9S3U/MJU7tp1KQcpf3K8+C4bY3OOw7v3MJ04t/mT+9hcBXm96wfNvYrfksz95Fpr XZFvt2391z+uKwBzH5j7QEBAQEBAQEBAQEDA3KfTCoTvs9OXubTvly1bD++7wn+GWvCQ7TTT 0Z9ky+nz5pd32Nk73aLUjWSWvKEWqZM6GE97KD6teSE+K0lZXpWNVPNQ6CybtrBztWvRh9qF 5R1+QcEK8tLHKHUUz96+zKUvHFjikPs6rgGB8DOhKdkqfDcPM37xw16WvWdlbiqFGecR/dwp b3cvieuX910VPyMUZZE+HPvRV7J+CvJSOH3u0o4jV2nqZN5Qv6YWa5syikXbB/eWoeoOLwtd Hk7uPeTqu8fPy9xU9tePeRxIqmM8FRYTryUvfews/1livCxiVwR0heztL+36cc+Ryxc10o3R 2XWqhwIDIiQ5zh+8wst0hf/sFf4TV6SO8dgauNf6ls4lENu0vIGK7qtLiVy6dOn4Ff6zrAJn z8jwmkYIysheZtr982X567aPfYpeQvhhn2C/W3u+//kU9/FLNPUqr6vE6EX2hdVtcnEaZqEY XzEJOVJF2fMnt/5jx08n2In1US/wqIgFvggippopa4/ytWO7KXz2Cv/ZK+yHjx7Z+sWu3Rd5 iBGxy7orxyNJzQhUVGZmqs9y/DTjt7t2X+LhcXjgnI8k5t13t1S8fOHo9zuZfjkix6dLTjVT NxCETdM00Gc9y38OVYHz/A0pLn3ILGkigiaF/Yiztd61vV/840vGvWJllnfJS/cBqhsI9PJT EBagfq3Y5K9LGkjYqB/+zy97T4jwWBc7lCDJVWPORtLcFw/+tPf49pMKV1WyvOveJOEf2zk4 c55k2f3jNsaTPBd1C23SYQj/ElvX5hHoKnhL+sIFavnZS9KBN7lELhzbse207Gn1Eq9ceOOT jM7M1FRXYWWhlIG9flHEllvaToR919e7WQ+Lx5jEDW4q6qiMOjNV/gtX+c8yHfxp7/Hth6kF ZrkM7pqgs+FXD4bHQbramuiimqQ9aZ5sktYfTk6QglG9dvnskZ9O0pSBZeFV4zIsd8Qtx5MT pCQU9xtxneHT9eFVNEEXtmW6ocmpg3XJeUE+JoykVI+HxGZICtxkvcaD3t4cqvH60QPh9QiE X4bwvbbGxlznj+zes/eH03KnNUrv5MJQOd7dw4H9/IWdX+3YdYqd3TDLNAOB8C8gfLrIOdaj e5gP0dSMFWMXcpIPexzc/JZ8T/Flcm2bR0CQhJAcG00x2OsXRTCidk0uOfOUSf6Ganuj4oJu cXDs277n54PM5+S9VaOmUpIcrpy6tPfgrWvqMWbpI6lukqdYru+6bCZmVxfa/DqtCO/s7CIk JkNTgZZFnF3YTi6k0btihXgDIzYlz0zi6Nd72A6fp1mcs0J2sm71PqhqpR52RvwsO384hi5s y818Q5BNJcM0kVyrtvkVVIQ3Ule6dpOLUtT6OJexqKKGCP+NH747d/iyg076QBgegfBL2Lp+ /4ggKRGaxeFQc+fgkOak5txHIPyr+JIO1ztx4vzXL1+7RTdJSYcKj5yZje/YBFyLi5k8C/Oh razGAjouurp61B8KNgUOaV/N8CchLagrWPHI3cyI6xZNteHjXMaiNkXocZNLOjx8QiRF+Jmp xbSlLnFqyRmI7d9zatch3uuaceb5NCXrU6uHwj1kWA7+tJsNQ1u6drO/PFMJUKmFqSEH7STP sqnx6UQaxj8PqiE9mpBc0uHi7ivAffUcqhkLlyKXYYnd3dnYRgTCz8cV1elLCF88unPnvtM/ X7XgtmlNaV6FCosNDbSYj57asXXPHlY+Ptc290Li6G8h/FxIkp+4sOjJIzdIfZ7juCTuIO7e 7IqbT7u3BuGRuLxKc0vDK8zXyD/IN1n4tDgUwuRv7tp58PxuHg/KPfLwQC9ZGamzV/jPsnKe PXPwu60Hdh5iPXGF/+wV4bNXNBVCu/2qEaimOzw6gPvq1b0/7Pn50Pnziv7qiUjaPSQ80EtG 5Nq+g0e37Lh6hs1ZP2MoHI9EppabqJAvymmm3bv3/nvHefIG1hM0yXXHI+l41Gd3XiN/djIw NkXx1rVju77+4cCV/bf9KZOMgmoNDfS5b5LjvXLtoqg7p4j5bY4TzJvPuZ8/FuedqCIgcPgi pZquFC+nvqyD8dGfjh/YzSmqmOiPRcpKP7Uz/hcQMPeBgICAgICAgICAPlsBc59GbyH8mJdv tKbuOpUJxbQ8FAK6gstf030qMrXC2obSLNIw4uk7RQipPWsQe1Z3ETEucMFNfrhVikegmu6g 2DQFVYwoaehANZcaX2qu8PmonAZLY4yEGvFdd0W7PMcSkh+UkNPk7HZHRN1FxLjQNXfqd01j XTW/hKC7uhae9MtolqYf1bf+R3BVGJcAaksDyCKhl+auQ013UAxtvK6lnjUddjZuCpoYJbdq xzyaDpNLuwL8faU0ycUt9cPlfNqSGulP2QeHJ+ibEjt0ElFNtMkavZNabmWNEdP2VAjsCSl/ DeFfRGXXWxhjxNXQsdiLqPoZxfcH125mWYhqWoCguzoWHutWT5XQ9dFNXIwgdls9GBeXIK3l sG5LWetU80wE24JAFfedvaNkaYviJpd2+ftRwg9Ud6vzo+6NsVCoQEcVI4YqIiqpH2eFex1D nzsbb6IhfmLbjq9PqavHzEd8QLBoFT/0CUCVgdWN1favDapsNNJxllb11vJvvVOJYGtnfDzd lPUwIqoYEa0AWfv64IZlLL7HKzhZjfxBOY8W91ziMWpiedIgRZqawN2YkFJLK4yIpoeIEz6o ZJ260+/XdED0XX19am/KHnW2CZ3+fr6SGnYitmVOGeudon2/4vKfOjtgJNTXuXzKHnVOtDsW ahiPy8hV03KUoDZzFlFNwuDG0QVLg8Ji9Uze2Qw2kHkmkoJ6DIho7kt6NRkGldAUtjWDjGLo K6xia6d9PFyUqb97DiKq/saJgyGkK74C4Uc9vMLVdTAiqhgRTU8RZ3xQyQJU3ekflSJP/koq e9Y75xMvylOMfZACfchB6h71/vRFBYg9h5F6piwOqasNq34sLiNXVdNBnLhDbDIs0hdTC4lV cD2UHYucC16kpkFaZu4ienG6QU+jiE5xOd7RM0KWZpLBGh4N6Ekml7T7+vqKq9vRLbicJ/1Z /ojkIgsr+usioR+gl/wmivb+X0xShrG1G7UZpsI5ocE/Eiuv6iyqmmyXOxGNWhx3z1A1HdRF SapUVUYX1CVfwepJb3cnJdp/ueS88HST/E0lFRNI8WIqXDIfB6fkaVN+cvXiqUtHUfMCVFxp bEmpNkyKyCVz6t2efdArqR2kYF8WWlCmb+Etpeqh7FTiUkZ7Nr92BArVOc1085JquvWmNsO7 al6AiiuMLWgnaZhpkzIQR9syFvfQyR4jRv2pd5E2TrYpWCEX8n2ZWP7UztxBTpPYQ7RyQEdq yypU3urgEU7ZSJrhA+T6yUR1efgnqFKH9tYJeuhThW4wF5FRaWZE+acNI4fJMkueDgsNVjFw FDG/a0q+pxiTCBlZudHtMcreMEkeDa1DoPqRmPQcZXU7cXJXlneRtFbiZ12JQYmoYu3yJ2Pw SCzugaM9RlTt3Q4xIqrBmneaAvBIOn7dz9LO2YI6SQiPhCfmm1tSu1K506zv8KEFdZGyrO5Q 31hZWTtSNV2lECurqriSR9aGfsqyHuZWZdEZwNwH5j4QEBAQEBAQEBDQ/7SAuQ8EBPQ+lWeo iHHt/oXzqE5TXP17SxMD/QlFMfcdSj79ZIA+msrKdZT1uURcdPPJ2XL+mlrClj3212I/wekh 5dMW9YcPB/RHqmHcy8NP+Oo1ztCl4OpNm/tA/x0Bcx8ICAgICAgICAjosxUw94GAgN4jbJA1 /xXWny+bqdAk6Af6k2s5peFFaGqr+lUmQUy+adpYZPlMbN3yZorTAv1ZhK2dji0biywmy9OC V9DgkgbunWcg/gJag/DLSVVTMaVjkcVt3nFRfHu/YFbO0YnbfE1goE+qtMaFxMoJ6qZNwuqq 6p06Z2vUtBKLB+b+n1TA3AcCAgICAgICAgL6bAXMfSAgoPfISYf3PLvoOc2SxGZSWmqgz0FP Xb1tLm7d/s0X//z3N9u+3srIeEbq0uaK0wL9WeSoK8TGxPjdNrL2K/BalXpVU6sc/4X0GsI/ 1RW9eXo343fbGLZ8992//+9v//ry+69O6/HYbrImMNAnVXiwrzzvSeqm3Xr5lICPYdlcYuta GjD3/6wC5j4QEBAQEBAQEBDQZytg7gMBAb1H0XcbXRPw7tnTn3wmQJvRXEzhExcfnIUPztwH Z+6DswxvRFfQBfqMFJ1R7xpKuo7mPjjzkPs++dNJn3pWf4yI5WerHANQ8frgzMPve+I2URMY 6JMruaTdP74YdRGrnLA9lGoNwNz/cwqY+0BAQEBAQEBAQECfrYC5DwQEBAQEBAQE9McLmPt/ TgFzHwgICAgICAgICOizFTD3gYCAgICAgICA/ngBc//PKWDuAwEBAQEBAQEBAX22+i+a+8XP VnMeAgEBAQEBAQEB/S+qZKKjarUK6M+m9rV2ZKNUIkgQEBAQEBAQEBAQENCfRtEIsrDh/57/ XfxtYvrF2OQsEBAQEBAQEBDQ/6DGZ6bGZ8eB/mx68XLjJ31eI8g8EBAQEBAQEBAQENCfRgsI svoHOvoo/jY7OwsDAAAAAAAAAACAPw2Li4v/nf8ZAAAAAAAAAAAAAJ8vwNwHAAAAAAAAAAD+ XABzHwAAAAAAAAAAAPwmwNwHAAAAAAAAAAD+XABzHwAAAAAAAAAAAPwmwNwHAAAAAAAAAAD+ XABzHwAAAAAAAAAAAPwmwNwHAAAAAAAAAAD+XABzHwAAAAAAAAAAAPwmn97c724tS7PgFuHn 5tYLiirIay0LtODm5ufmlnbAptb2fNq5/W/SU4NNspfivi3GbQlVPQCX4HfR2VyUYs4tyMfN rR8aV5TXXORvzs3Nx80t7ZSeUd/7qWcHAAAAAADgT8rnZe7fjzWyVeXnV7ExjKlGkOpYI1UV fn5JAze3/KFPPbX/RV5P9XUlaGrKCfMbBIUUdnzq6XzerL5dbo3Ss1Lm51ezM42rfrtcEaWn rMzPL2Xk6VkItjcAAAAAAIBPz6c39ztqoUjRLd/95+9fXbeyT8mshSxEt/zt33//20G50MCS wU87t8+Kwc4HDXkhKbUjY79z1QbulxSF6GvJcOzgC8ipbvs4s9skPbUpJWUVRY8/Wof9zx7U JoflPhntHvtofW6E9kpsqPCWr7/4+1c3MK7pmZVYE+Etf/vi7387rBQVWg62NwAAAAAAgPX5 vMz9RhcO3sNffHGY55pTMYIUu3AcOPzF3368KKOEnfzUU/uMWFpbG7mXnn/vec/w7+xobmy4 1D/AjI9V0tY4rOXjzG6TLA496ajNgJ4i8KuP0+Ha6mpncWrDg7b2uY/T4QZZXVlqcGDjPPjF v4/yc7oVryzlO7DtOfjF3xhYFdVTp/6rUwEAAAAAAABYj09v7vc152So7/7+y//bI+nvW4Bv zfM1Ovr3L//xH1ZTKLHl007t8+J5U1ak+SXZ0O6+57+/s76mNpw5s2howScy9/HBss5u3vb5 H63DpyV3Q6TYzAp6W/s/Wp8bobchI1Vl1zf//v/2ygQHFeNbsj31j/z9P//3nysW2djW/+pM AAAAAAAAfEZ8XuY+IURY5PSWbcwS0rFdCNIVJ3ucedu/9nPq2lZ/6pl9TiyuruKDhDSDodKP 4MevrSJtgTYOwXafyNyfbMLmOosKpyC98MfpcPXtSoEBv1dMJm7g43S40XFXlp4H8N9m+uaH C7IKCV1vl9uiJQ6d/f6LQ7eMHWr+qzMBAAAAAAAAWJdPb+4PtOCytfZ9/+UXLPppsQ3w84oU H84vvvliv7BnHq4dhmEYnpmGJ4f6ezo7CAQCob29o3tgbHpyGobhyYmxgV4CoZ1AIBA6e/qH RyZhGJ6B4dGh3q4uAorOvv7h8UnUoFPjw8N9nYT2DkLv8Njo0HB/dye5bffA2Ogk/SSnJsaG ewgd7cQmXd29gyNTY4PdHZ3thI6e/v6Rdz7wPiZHxwa6Ce3thM6B4fGR4cHebuosu/uGRsfX G7e9ndKmvb2jZ2CcGD6RGRieGOnv7u6oyY/11jkn6tF0rwbVunNgfBzVmhL+UF8ndeSuvp6+ wfHBnr6R6YkpGIZR5n5p62AvcS3bCYTOvuHx8amNxroOU+NjQ73UgTt6unv6hwe7uwZJk5ye HBsb6OxoJ5S4iZpb25skoS5iR0/PwOgkDM+gVmdquKeDdnXejXd8qKe3i1CVFuMuxKKd3FLc SmndQegdHiMGPD05NTbQ3dHeTr0KMzA8OtjT1UUgENq7OnqGxqdn6NZxfLCnF7XPugcHe3sH B/qGxlCT7G/MhDT2bfnPvy4a301sgp+WJHje+OKrf+0X8ynK79jM0k2Mjg50E9o7CJ0Dg/09 vd0d5FlNDPd3d3e8O8np6amxoe72TtTyEAi9g2MT62zW6cmpsf7udvJStnd1dA+MDHT1Do6M 0F3viZHRAdSe7err7h0Y6euk7hwYnpmemhjq7kYNTCAQugfH3/1a0U+yvauzZ3B8emSgp6uT QOjs7usfg2dm1huXQGjv6ukZmpyemXm3UwAAAAAA/gJ8XuZ+Z7iY2Nnv93BomJUgCIKUmp/n 2LPzjIh9WCe5xdvXr+ZnJseITM7Mv3r9FkGQVQR59WJqcnJsbGxsfGISnl9G3q4hCLL05uXc zBiK8alJ+OUygqyR+1t7u7w8Pzk5MTY2NTe3sLj8ao7c+djkzNyLN+tM8s2LKfIMxsfG4IXl N4vz8MzE2NjE5OT88srbtXU+8y6rK2uv4KnJ8bGJGXh+8fXyAjw2Nk4eeXLqxSsEWUU1X1tb Q41LagbPv379Ft3p26VX83MTPaMjxW488m6R6YWo1hPw/Dxta5rwSQFNjsGvXr2YXlh8/XKJ 2IJs7gfVLi1Q1nJianbh5cqGAl2ftbdry/Pw5AQ55ImxyfmFF9Oz84sLr98S411ZhOGp8WcF oQnmfLdCx1oI1FDGpuZfrbylrs/aGvLmxdzMxBiKCXh+gTbelTcvF6bHRoaHk1U5Mb7R8XhU 66m5uZfLpK5WFufhqYmxycnpefJVWHqzODdNWvW5+dfLdOu48mZxYRp1YWZm4IVFeAx+ufyW skirK8sdIYKCp7bu49KzKkPeLi8VG5+6unsns6RLZNdmlo64cybGxybgGXh2YXaCOKuF169f v5on/jU2ObdAneQagqy8Jm5RVMAzL16us7up4VOCmZubnXkx/2KW7npTpoHaOQvwxIuFV8SF JPL29fw87cCTMy/m1xuYfpKTcwuvX75cnCWu68zC8puV9cYltX39enn13U4BAAAAAABsik9v 7k8/LXvsxvHjlv38zjlZz+Depuw05f3f/T8OraTyGqJdODEIN3nq854/zMDAwLB375Fbpnnd +AEYhptrMi1FGRh+YWBgYGDiMwiOfwTD8CgMp7tLXLvIgIJJ0SC46BFq0PaCAD8FJoZdhxjE QrKSPQN0bzGR23JZZWGb6SdJqMkMEmU48AuxyaXrUjaxnThHnsPMexgO8xkYxD+i/8D7aErK sOBk2LmPgdk0sCTc11GWkzpLbnkXbClt87bqjCBRhv0/U9rs3XeUz6yg9/4ApckEDDfF6vLw HPph23dbvvrnf7Zs3/4DufXOfUeZzQpKUK1J4ef7+8ozUUe+pMCv7ljkxK8a11tHvKFCMfc9 9exlLhA7Y2BgVgoqLd6UJf3OwHnecucYGHYQxz3Md+O2Zqgd91W74tIHgzAM99/LyzY+d2D3 jm1b/vP11998tRV1EQ/zCRgnNsMw1SJ+XvUsUOTwXurq7Nx/nNm8kNgVhSIXUekLDD9s/W7L f/715dbt27aTW+8+wiAehqtvh2EY7r9HyDLiPLB7DwO3okdaKQzD8DAMpzkLX7nAwMCw98IJ Ae/CvhG6NDpFzsLSF6gT5LG1lZHGGMvfyYBhyk2a6cdFeOfrW7/cJ+BRgHsO99RDSYoHvvn3 Dd306vpN3SZpTEg1u8nw036G8xa2OrxS3IcY9l48IeBeNFAZoM3FfYiBYe/FEwLeRbwKO58A ACAASURBVAOj5En29xOy3G7uP7eHMsE9DAzitnkN997tvL/leabhzf27dpN22cWj18zCrdhE 7WLDSzppWjbEp5rdpMZ8WYlTxjRC9ZxiTG8TeWOM9z1vdLt58+xu9FeQB1OQvs7AfX3PM105 9pLa7rvEJOhcMhhvIcjKwsDAxKlokAkPTxDHjUsxvYHucN8lIUGflsGx33OvCQAAAACAPy+f l7m/nGeodu0sk6C1/1MEQZCnAQKCTJevqgTlUezCoSKch8x5RiLMMh64oiEEQWYRJMuR+8J5 RkZGxkOn2FXdnyCjLxEEeVCdZCLCiOLQTXbVuCcI8pLc38tRwhN3VraTuxlvmpj5xhIyjVgZ GXczMjIyMp4XNXOsXGeSFQ6coqQZHGZkVAp4Uh7qpSLNxLjnFDur+5OOsY2lj4H7VjOVOM8f YmSSUb0TVvbIX4mR8RBpliwXuB2zEGQW1XxtdbXCgVOEmRLJDkbG87JeecU0mXeGHuS4GzIz MDJu2/Lv/7flu63bUKGflPW6U0yfp+flSNsjN1ZWpt2kRkcu7lS+m+0g7BOXl/CANDDJ3Df3 fOArTOmMS90nflOW9DsDrzx0VWJlIoW85/RPV9wCrW5puof7FA8jCLK2utIZo6TIcejHbd9u /frf//6WcTsDefA9p39i98zuHJ+h9Lb6FqmwNxJmZkTHK3fHhzbenop4H2FGRkbGrV9+8c2W 777bjmrNaWaZ+JAUb2e0uyIHEyPLJT6XbASZQxAEuV8eayDMyMi4YyfjeZM7+Y9HaKPpLo/1 EaZ2dkFSUsknRmWXWvzzwX7KFXy7vIzTVWA7c1rUPugZsrqy9MT3Ft8JVg6tsIJN3SaZ6V6C FDnOHWQ8KS8pq+mtf45xx0+M5018Cgtz77ron2Mk//mEPMlVBOnMd5WXYkIvD6ekdfI6z8Os vkU6ol3lOUhtd/zEeN7UXEcS447RTOymaTndtQQpXjt7kNTf0cu/KKUHK521C0jHPqK2Gsx3 dZI8gR74gpSt63oDI0hHnoscqe2OnxnPm/oWxSVE6wsxMv70yx6xYEID8UmL6c7X6QrUcRkZ d/y867xpbtHTj/RkBwAAAAAA/8N8enMf7q5vT1Bm2sqhE1NaMQr3NedkaB79bo+CXVYDyTKf noQHWmvjTFSvXztzRto0o7Cqc3xwAobhgV5Cflaw8tUtu7nknL1zHz4dhmF4CobbWsvycrAo XPQN5LUVrONKyK7raOeD+3mBoTa3D7Jw87EI6xjauWCx2IRorLuEMLesqn1aLoEyP0Jtiqe9 srSwnkd0XCIWi8UGu3oYK3Le4GM99AuPpq1Dal3d0+GNBjvwjNCQGBGmeeWUpJwAn7aJhZUf eZK+lmbqEpJatp4l8DDZGx7tJTwswaanUiIJjY4wkuPgM/KvLCTlo5+G4f6ntYWFULCXlY7w 4auaEVHB5NYp6RnZDZ3dQxPk4Sdh+FGOl76GrIKMgQul02AXMz2hc6ynDvD4dVYSc/r0NbVl aDMfOHflkriGpZsfFovFxmGx1rqSGpZu6ajF2QxtOVhHc01ZQxssNoE4sI+tvcyVE8d379fJ KWjth2F4YqCzvT4bSkvx0bgqI6ckiUFdxIyi4vpnAzBMPT4/0jvyoCQDtTpx0eFWctfFjAPi ip5QWnXdKynLwQY6WmpcOSpkF+kTTW6dloEtfdTRPwrDMDwxMNpeVQB5aV+VMfeIzyetVVtL SW4O1s3RVu8mm2N+7zDlJsloX0exq5iarqmlewgWi8ViE7BYdwslTta9bNduOyTDMDWxf2fN 0xilI99c10usrB6DexsyUtWPf7NL0SmvmTrFjdD/rK0hISxQmfWHQ6euK+g5+EV6O9lIXmbn uSSg5eHghw10ttbhZ9XP6GvthWEY7mzOS7PhkjOP8Qsnx5sQg3XXVpJSNvbLzG9H9dxdXRXj pMqtZBoTR2obcidEm4/l8LcHZf388lAXuy4y1NpQVt3aE4tNIu4cZxMN3pNnDu/i8e+pJTec Hh/pv5efn5VGGRiLdTdXlFQx9vOnGfhBU6GXxW1uKZNY/3DSuGEmoleVuc8wXhSQMHQrqKgl wJPTMNyWleiK0dOwoYyLxWJD7jgayNzitc6sfQjqEgMAAADgL8jnZe4j970sbovyKfhmziMI ghBChIWuCvGZpeIpDV6ODrckxhgL7Pwbi6JPYlbb8OhLBEGWEGToWY2nEecVjgsyBon32maR VysIgsAT/Q/rcShi/CJM1a7wu6Z0jo4iCIIgK69ezLZVVERriUsIXmIR0RPTs8PhUnE4XLSV vZbsLVH3xG5kmnTQ+MV0f1WiJr+8rqNnaBIOh8NBSThfPUVpuZvnz3ELSWrHVFS0zb57On59 lhbXhlqqy5w15dUEr4mbGirp+eKSIRwOh8MlhcQ4qvPfFrCGuh+Okpqvra2NP6uuL6VEkoPD eWB0FPVMQmLvU1cHHm57UJqek+OjfoFbw9zRGxV6cROBMPoSNYOJjppEH3VJdjn7qIRUYpv0 xGgfXT7+Mww8JvGkNDxEc1/+9vkTt2SUbXxxOAiHw+ECfR3NdBQ8krqRmfUebvgN5tr7SoO0 rspbRyXEEAdOicvGyNxi3nlMytkBN4AgyNra6nxvS0tVQeIdE1uZSxdNcJFYciR5JbmVhOH5 10uUDtfWkPGnD1Grg8PhAjHa2nqmpnEPKK0Wxnvb63E52VkY/vOKehY20ajW1Y8e98GkruZ7 2lqgABNTdT7zFASBEQRB4PHeB/W4pOxsY352y6BM/CAqmva8AD8bLRXbUHJfUcHuGtKsF3b+ U/TO4z6qI766grS6G/OICKgFZi2Qs/SwCwvZQA+QzbC0sDrYVFXqpMZznZnploCBV052VrCB qKwoO6+yvoEXLjsrCyNxxTTgbnYngpAK+So5Obo5BKHijXJzN9FR1PNK7kFmKev4enKlPd5J StPcLYDUNicb566jxHn0BI+8RHg7dQ7D99pS7AUE9J3jscnEnZMQeUf71vWDX98wjItqpTZ8 OfL8WWMxeuBgN2NdRT09bM8IdeC5laXySF1RHV13x2AcDofDZWfh3HU0DUUuXr5x7bCIWW5e aeeLqUUEmSN0lYZqCRp4kMfF4XDZWXfddYQVzP0jSn7P7SYAAAAAAAB/BnN/tHMIfzfALgZ3 73k7DI92PsBn3LG7k1HysIvmoHRPTQpGW15ARr+oo5+cKmS0q7Y+UeH8GXm3hLqHv1Kd9FFS gJacAL+Bfwc8TDnp29dMyNQ6v/fYFS4L99SGRzAMT43B7fkhGvwaJl5e1ZTPJke5GclpOQUW tA8Txx148ADnbyvGeYLxkIxPXg4xKf3UGNxRmBrs6Wi5HraOlpEV+DbiFJ92P/eRPniKl1sH E1VW20MNsCTZ1lRfR9qg6N7A+HvKvvYPdmb7cO3mN4gJLqULeAM59ycG4WZfaz0tJdPAyALq 0wYD90tyPJVlOI7xBXRRzX1Ih3k3G7+6T1T5wx4YJj4ikGslb2ziaZdHsVN7HpSmxLmuG7Ol pWVQXEETtSYuPthVTUNA0juPcrC9va4J8rOwcXCFHjymLXT7YTn3JwbaG705OfgNLcPK6Rzf DeTcH4fh2mBZHTefeNpha0vu+kixORagzP2hjkfxEluFzShFcadgmFCd5OeP8fSNLqR5vGC0 Y+Bepp9tdC6e0AHDox34e5C3rVdG2ePuzZfTfdLxxEd8zxVJsxioqXO0NbfM6uKWY7cMw2ua OuH2Smy82gmhkN4aAgy311UleWhoG4aVDxEow0yOwIS8JD9TI7tgnzTUnYXnmRluOueZjBJ7 h7qJr/Q/6SkOxVhbOMWVVzxCTTPH3EBNm9MktYN8i2UAX1QQ5Wht7xpeMdL+3ngmYZhQ5SIi I68n61tLeXXgfmKqr4aYjGto2Sjps31Pegp8bFXZjjPclLZLKCR9tr0myM4F4+WWXt+BurXT 96ShIMhUVdkksvD+46FNLyUAAAAAAH9yPjNzf7KlIjULwrV0kv5KTUmEUiraaMrpLg73V8eq HTqsHldVO0x1q6fuuZqqqKmYJLb8SvHd6ccEyJb1+8t2ZYQnaKO7LQgjx81yTkrbpfgxgrxC EGS2rSXRwVRMWK0E6X+BIAiCzDzpKnYTElB1ScE/HV5EEARZeoGMlKXYqQqdY+FWsAshkHub IzytwPo7voeI3PxW4onyNQQpDDGSFjwnomafWjaCvCA+oLA4NP4I648RltVJy6gbeU/Z1zUE 6SzxkNOV11RJoSvHurGc+8NlxTF20so2dimPR8nFaokVdDEiRyVtE2nMfRnRq5wGDmktIwiy jCAIMtRZFBSsrCCcPNo7Q5r0i/HHFcGO3q7rxhwQGFX2lLiwCIJMNj3Gmh3ZrhHzZHCI+MrL 6bcPsSE+rp5JFZUEmog/OOf+YLGbk478NfW0UdKcSWws535/EzbCWZxi7hOZeruSbMDvGENr 7jcFKllqo4vizg4+Krnr7WbvkFY7Nkt9vGBtFZlsKsNmZea3diHI2urbySYsNiEjvYqw+XK6 bxGkIEBHRVLIxr20a+3t8mSSvPhtbk6DyNIuUuVeC++UiHsIsji18ijVydLIN62hFf0Yw+yz RyWh7o4YzcCnw1OvSS8u9C81W/Gd1XRKaWgjLxbSUZAV7e0WDkH3UNNsz2vwkf8ne0BlzxTx a7Q0OzpY4u/n4RCKe4D/tTrOswPlQSFq3Du1y9qGF4gvLc11D5RqaKlYuSU+JH129S3SUXDX W1nw4o1zFy1SSU+xzA42ZqU5WGkFVzycXqB8fVffLncUBHnb2npF5+GnN72UAAAAAAAAKPwJ zP0N8+iuu7sqF7Nicn3f6CgMw/DA84o4f5EzJ7SxuKZudMvu1vKK3FQU/jYKotK8SnZ18CDl FHtfMyFT7/xBXtPQ8roe6mfxoQoubl62eeSuEnUcHZy04mkPqw897CzC8P50QtmLbO5PDsOP Yj315EQ414NPmNM8rQJPnOTT7qd3pLfvlbHPTqdP59NcmRWgeMkso3uQNKPR3tFHZXcz0imR JMWEeUocuKrp55VDV+r2t839qcEOwp0bCvbxAUU9dG8NPampizR0yhkgzbGvqS3LhPmybUzx A5qmOEtXVzeV8Pvkv9tqkt0xkuvGzMnJqWsXXdhA+WxbdrI7RlfNxis1NZkUTWZuScP9AXiK vijABs390fGRhzWZ0F3U6qR6iF9j1zT0yX1A2/TjmvujfYQiF04DS08Hf9QuK2om37/5g3jS 8SxE/IxpXCGeAMPwk+JH/qLfCgZn1hBgGO5tyMixYBMJ66shwKNlAbFW4sdkvGISsKn02Gpr W2oZYdspRnl3VVWCm5qIgXN8YiypDZSRVdLYPTFMlyW/NsLH0UrOyA3VW15h1f129OMUMAxP T8ADrTWFOZnoYW1EbktrCzgWkhsNNcfZeptoaGeRE+8QGe2CC3UETgrJksz9URgu8hIS11Iz dngnksSocA+xy+r+udD999wLAwAAAADgs+UzM/c3xvzwsyqz/ZyyPuFl3TCCIMgSggyXWPJL ajrZZLajWy5O9nc25qHAxgdbi+08ZJz2FO1VIm1BGAV5CbWgfJRrO3UvLc9JWBCLdM8gCIIs Ps6u9pI669ZFGKM9rD6YekdeSEIaZe5PNNYk2Cnxvge9gOCCDgRBSOa+mqA0v5k7HqFldnU1 x1bIOgJqJJUbWFtDJp4/aixHBxNjLa6mqiJMHZgU9EbMfbjYNdrTWj5+iO71tbXVwTznlLw6 8hxXkbZAGwNHQ9cimqYdhY+jtA/b3G8jPQ0wN9VbEa/OKyO4bszKqkYx1QhCcnPn2nsrQjVu 63vEp2BJoRTk5Vc9Gp6nHuYmszFzfw1BJnofNdbQrI6VqarqdfGw+6gsTMgfYO4T8txDnPQN vFBDVzTVtf3KLabfz1sEKQiw9HJxym1HEOTtMlJgoGDgqhNxDyFX7rULzoq4h6yMPZsKvXlN ycnaPyWPnvCwMCtWVt/G7inSb8TriZX2eEc1cwfviFhqs/KWjtFxulxTQ/eepjuxyzvEJkPk ZsX5BfiuF6/of25ejg61NdHs2nA7Lx3BL8RSn/YT8069gbtqcSondJI66gZpP9sWH6Unz0I1 9wnVMW4G7GJmeXlp7wQTY6lma+fu1rDw8RcbAAAAAID/GT4ncx9uL8jz0r3ws6jr/c7Hk9Pw ZHVpoinPjuuWOGIKfhiG4ZnpqdH+jhTzW4Kntm6n8v23X+08yvqOuZ9rfl4sNLeCxgynM/dz bTiNTCwpf1I+3E/Iwpw/YxyYR++x/zZPu58GSG8Xdk6vrKd/q43GoJ8cHWvJqbG7uWv3jm3k SH74YdvWL//5i6jHB5j7w91PE6S2KTmnxzW8pwU1PnLO/WraUejN/U3SmJBmdgN1Xfad4VSz yet8PkAtx0pkA+b+xMRoy/1qjPgvuw5QV2fb9q1f/vsXUbU/2NyH4XEYbozWvMl1ALXJ2PWs wkvpq/5+TDZq7j/PdHIU/OWfX23d9sP29bh0Q84LXRgAfl7x2E/owO6d5Aa/7D16UzOxtbqN vgouIdfbS+Y4KuZzV0QxkZ093ZQiz9OTUwNPunEmUpeP796GGvPbL/8fkxjK3G/NdNI1ltRw aoBHaS79IAzHmbMrmJLMfeKfTEe/2vLduqFs386kHBJRSlsYAAAAAACAz5+/pLmPvBpDHrvJ nhIzDM6ref0WWZ1CXsXoXeDWc7xbiHKgl17OPcwOsL3x3Y9Utv/w/Y9f/t8hleR3zH3HIExI M3oQOnO/qyQiSOks5U/0h7MwWtbadvQe+29DNPeNjDXCiujfojXoV1fWXs5MpemrcJ/Yigrm h2+/3HlB7MPM/eZgFSdjDdN3Bn5njuSc+2G0ndGb+5tkpmclQ4Hj7AFyKD8z7mBWjWqo7nuJ LseKbMjcX11be/liKtVbmesC7eps2Xnx5B9v7iPIED7TWf8sauTTt6+ZZtJX/f2YbNTcX+h/ 0Gxx8NCu7d9+v/3HdTi882fVIMIQpTAAsrqClNnoC1CCYfjxRyZhTFL6U/oquItDT+47X2I5 +jP5i3VgJ6OkU+2jxwvkIs/E2ryPEyOMeY9sQ4257dutvxxDmfsT/Q9SrY+fsM7peEB/7r4x L8BBhWruN+YFKF3955dbfvxx3WAOcWlo0RUGAAAAAAAAsBk+K3N/auxRYZwLz44LVrkF+AG4 OT7VVfVn0TB8x8gk+eTwaF97utbxywKapgE5z6kUx1ipawl+buZ+U1KGqfj+A9IO9S3V5Ege t9RkG5zk1Q/4LM39iZHR/i7UdcmBwjQF95+WDuupb6dpuAFzv7Eq3UTqwEE+x8Ysyuo8an6e ZSByS9/kDzf3Z2B4Yrivq4tADabIS05eWErQNKkFnZbnY7IJc99LX5DFNKfl/pPn69DR2TM4 ir4DMTU+OdRNaGsjN6isK7eT3LNb0pa+Cu7U2NBgTzu1p6rYWGvZS0yCVkUDpPw9fc3PM01u 7jot65yWVIsaM1ZbVdPoQ819aT2TwKT1Inn+/Hl77/DwOCirCwAAAIC/Gn9Nc3/tLbL04q4u i4y+o0vREDLbi2RJXpK9E5zb9gpVm/RBvJmB9K3L+skjVJ7iKyL19h2ygD4rc59YffekiGog VIAKpiVaH2Os+Vma+6sray9nJsZHyaE8GxwINbh8WtYklVjXlsIGzP2ZtysZ9jeYxNWCfGhW JyrY1pj7v2Huryy9fAGPU0d+UhgZosX5yzWvnO4J+s3ycdiEud9idfSaQWx08bORdRgdGZmZ X16hfmnW1pDXc/AUJZihkRGslzKPtDh9FdzVleWlF+PjY+SGna19eSbCzJyaPoWlI6QWSEe0 q4ygiAzmTi1qzNoEnIvsh5r7tgrMuqEjI4R1g5mE4cVN1SYGAAAAAABAw2dl7sPw6LOKWj/h c0w6HjgcNtLYSkqQy5vQPUSx9rr7OtMNr0laB2aWPkc5sTA+293QWORDzP3uRB0HB0f6tDzD DzuL7fh+RqXl2QRPu5/6Sm+/aBBQVEifHaelMitA6ZIpMS3Po1SfYD0ZOf+a5uGJUXKL8X5C nS2zoHHgB5j7Y31txUbHbqi4uUKP39OEzB9k7tPT31ufkKbNsU8lHddIsxa/be4/xOKC9K7K B+DujfRTV6cPrrWRFTA2+4jmfnceLsz6GptjHo25vw5DT9KDjVWUZcxDH9MZ1h+LDaflaY5L dNG6KBxaMzA68iEDjYx1V1WZsl9XC/DM/NW6v6MdD7IDXMQvXXOtqXw6AsPwED631JWXRy8t qbqHpoxCjrmBoSltWh6b9dPyFOkIUtPyTMJwW6waj5GlV0DTh0QCAAAAAMBnyl/T3EcQBEEm ii2MJTVVbWJLuwsS+Rn47UqzH6GDvY91sbc08ME+m0C9ODX0NMP60CHrjE2b+4uPsqu8pM66 d9On5RlK85YXpknLs1GI5r6iupRbHH12HJq0PPP9z6u0z2m5Z2Y8nURb3P13bTyttT/M3O9I MbXVkefxvP/+JsQ5/jHmPj1La2/7n/pIyOp5W6R2ot/4bXP/Re9KpbaUlrt/5tM+mtXJxHpY 835Ec//18EqHmySXbSC9uU/Pm5ln93PcxI/d8Cjrfv7iV5t+IBtOyzPTNYVT4hXzCi/6sDxB awgy3pNqidE35rvzq3V/V16uTD7KMLipbBMeWDNFnMYgVsnWztcpraMPnSynPa8hQAWdlmem qzZn3bQ8hPgoPfkLVHN/5n66t7PEbf1aZOQv+6sGAAAAAMCn5DMz9+HRzr76BB3mMwq6MnwS YoKiBr5NMCoz+LMeQqD0QWHH6Ip6UqHTMbijMC3YUunG9VucH2Luw4+SIt2MVQzvpLTA5BQl Hc/r4vwluU4yHpLx/iBz/7mP9MGTvLd07aMr6qmFX3selkWGOVnq2BW0Do2PwXBdlJ2jioBc Ykf/KPHBhMHOByVpjnoaV3cyK/msZ+77GZ69qJTcVE90VUc7h/BQkAPGK76MWBZ1aqy/Pd9G TVpS2Tw4vR5dcXaw80EJ5O2Iia4kZY3/A8z9R/kRObiCIprbCoOd1bHxyhdOGhYVtNJkq8cH yxpq6sr7UGqo9jwoTYn18nIOLX44OjEGw3BteKqD6hH5pKaBMaKHPNr5oDXV0UHj6klmZd11 zP1UH+HD1xwLy0gnzPuH+sqSneycg7ILm4hJXaZgmJCkLWFk7uRDXpyeGizWXVGSn/cQmyOO Yu6Pdg7czwn0z6l90kMz6YeJfobqkvIOiR3w2DtVBD4GGzX34QF8fZqvvrCkslt64ZMemnKz D/Oyo2MC4orvwTDxBkR7XXYRFJd2D0Ydfx8d6aoq0DpzSy/CL4+4OJMw3F6THJuTV0WzceD2 VpyvHefl2wEttYQxGIZ76yHI+OIpk5Li+6Rhx4d6m5IcvVVYL/CpoMx9eACfkOqrJ6kYBj0Y 6yFdwo7+pnh/DfbTjJSCujAMww9w5k5Gqupm8fST7L+X728XnFJRTV9Rl/C0MSPc0tLG0tI1 8d13AQAAAAD4DPgLm/vIZEuiiYqaMI+8vT7bIVZMFuExzcnfohAjYyON0EKKiT9HeFYZ5awj zfb9Ib3UTZv7yPTjriJXASHNsJIB8uH9VwjypMRVW5qZhVv+Q819IylBZhENR6hyFJknZaR5 +WICXx6sYW4H5d0bnkWQ6a6HyYI/KAVVlHURberltbWRe+khngpX+MUV1jP3W4OEuPWdopPb 5xAEQdbWkKl7lWnhwRFQRisp7Nnnd+PdtW5LGIdUjk7NU1LhLK2tjbSkBYfHk6v+/gHm/nRX awsuCnqKwNRM7kurb4danPkUjf0dcmjqsU42YSEzzmNalbWD8y8RhFi5tzzYyTs4t6ptZA5B kKn2lSQhdsXgkPJuYinetdXVqZa0NA8FUX5x1vXN/StqFp4+FSPkq9DZgosPD0iKLqMkdZl9 dDfMTUJYq3J0aGEZQZDFoSePIEd7jSuHzhi4Ucz9tVVksqUir6KopoOmKO70w2d3Ha8eE/Gv 6+v6KPc+6NmouY8sza4MFvtrq+pbB8fQT7JzsDrN2QWqn5gj3sBYnBp8nO6S0zqBuo+yhiCT bXEGGAMjyfAuyuIMPq6rSM2sGkUWqDmUFlfe3E9UuKGBiY26N4cgyOrym+f+fOrWgS55I5RG Qy052S4yqsI3UOY+sjTb3V+srqXmHZJD6CBdwrfIZHNZiI7cJXRBXWSqPT83UFZYwjWifKKP dpLPy1IyUjLv0lfUXXy78qgw1NfP0dEz6t13AQAAAAAA0PC5mfswPN7fUWx17vaZnT+fkuS3 wj2iSYHSPdiV4sbDqWrg7hhGrLAan+qpqyLFee7w4ZOnbsj4ZuXdH+sbhUe7Hj7IDw7DiBxk 1cK4Yitb27rhiYmxDnxRZqQeh6y8koRrQXYtYWxiCobbarCOzurSCrapcYnEQp6+vq46Iuf5 2A4cVv6wtDwEP+nzNwRYOWTVLaypFVn93MyNzQy94x+Rzn0/ygvwMRLkVPGMjScWoA0N8jRW un6V9cCWvdeVldyzyBV6SbE/qYm6I89yQcjOxTcmNTU1NcYvCiN5g51bzCYlnVQyeBKGH+Z4 6umpaKhZo0vBhgZ5Givzi/CYp1fgu0e7Hj7IDwq1FTlwWcvePaWyta0bhqfGRwg1d/OdReXl 5G/qR90tud81Prmp5DM4y+tqsuJS9uiSqKGBHkaaItJWUP992ocY2rLdrZUkbonpkqvv+tkb yItyiosbJtQOjg3DMPwwN8/b8BqXikNsArEMbHSgh53SdV7W/Tv3cvCqeMZV3CegCr12teTF m7CfuKHp6BWampqamhocFa4hzMLDpRYci7rhUBeloq8qK6ZLWhw/SyVVsYssFy7sPyaLiYYK H/V0j8Fwb+MzSO/sQWEdB78wdDQuunrallq+eY/JvvnHpP9ZW2NiRIgm6z5hPK3sMwAAIABJ REFUA4ew9IbHz1uKH/kIfHtZy8ojtQpPuN+Qcdfo3BXdWI/UZjxhcOhxVbm3oiCfmqlPCN0k deW0FTHxpTBMvM9VE2ZgKXaewzQ1LonSKDr2/2fvvgOiOva+gd/nuc99b0uPlxKTqImJJtHY jcYeFQsiUqQI0jvSe+9NegcBpa10cEVEwIIUERGl7y51ge27HDpIPe8fC9vAENDckOT3+U/O 7JyZOQX5nrMz15wMJMStoh7fm3txn4ogZWGKJ9UUtK6E8lYXGOBuonrOPKyM1EJGEATpqXtY GKC+74KhT9DcbhPjY+yVj8rsW7dhx/F9Kv65RS/aGUwGgiDIi6qCIFtJGV33pKi5Qxh6zU1D QuP0HtEzejzhPoKU3Qo3M5G7rO6Ulpwq0Miz6m4Z2ZWd/INVWnhd5+hf/vJ/f/nLJzIBIXf4 p3wCAAAAfg/+yOE+iuKzHdyl1m/cuEf4XNKdVtYA38bnd66aW6sYmUfPr7l53e+q5aUTh/du /PdacauI+DJiF4JOjQ0O4B4+um4gr6Qrrx/1oKyZhKIT6DAVX1MSae2s9OM+y/y44lYiYwRF B1jEkiTdg/r28SFz642m5+e7GMmoim/7UX7F0/I46cnsOaGsqG4cko/Jnlv1F3Pdx0hCL/pR d+sgiqLoEAX30OOQgp6Ldzh7Adrs27eDHdQUJXdt3Lbv2I9GSfk1pIERzlq047Mzrfme0irK BroO7Ibezo82u3JZVlLb26eA8x0BOuFxUrDeJQnjkMSb2fNjlHX7drC9qoKCcVhEAWFqbLC/ 5eHDBH25S3qKBtEPyltIKDqBokhX3cs013Cjs5/KhURlPcOT+8cW697rEO5GBsl/9aNVfnxa Pne/2GB7VQWH8OK7BL7CA/jSwquaO/fIO8clYfLz8/NTk685qx89LKkalFrRxkBRdJA09cBD XV7X1Cd8rre3sVH2qtqSu3Zs27f5oEnonZqmgVHOZTA7M1VzTVVVWUXVLGhucPJdrDWUzss4 mF/nfo+B9Dwj0e7kHvmQ+OTs/Pz81EgfNx2xs2d3bNgoqWEXlfucQBxG0dlptDnUTlVTRsmJ c5bl5+fnJwTF2hseNUh51Iu8/Rf3J4ZneqtL73voyKpfVnJPfFyLRybHb5uoquuIX4l5WNHS OzVRHyphau18JaaqooUxOz3Vc9vd7Yqhns3VGP5GxlhoH5H0ziDSqSiKoigDV5l84f/OGkV4 xXEK3c7Pj/Ix17ZxirnBfXG/qzLZ1ezwIfmQ/JQcTsm0W3nOhlKGPolPqhkoiqIz05PdWDcz YxM9+2BOoTAnff0zW37cueVvB20i0p4QqANjKIqiA1MT92MN1KxsAv1vsHeLzY+yM7dWOPaj xDmecB9Fe3uaktwljmpaXw9PFGikloGp39VCEv9g0SfGb1z5Zu1nf/nLB7sVFGPxKAAAAABe 7/cX7iO0bqTU/vKPmw9IO3oWLdhK70GqfI3O7P56brnNz4SEZGxzUoNDDVW2CH22cYtMBKEM h+DvhAapcNYFFbvsgSlCursJt3xPf717nZCQkJDQd0e3GmQS5iZ8wdfcDTLfJbROlF3+6z3i ao7YXIudK51zHxd5aa9VQn6Ev6vSSZ6lQfdd9vDl6xH+2Z1Anv0KfXdMUTuBUOwqdnr3OqF9 lxV9Bfrf0tESprP5i2/miq/f8M1ZyzudtQtmk3mS5GzNu2Mhoe+OKRpmIt1UBEEQ/J3gwMuc wTml4nWzCEHI7U3pOpsPsatev/fbc1fvdJJ6BCv+OYUe0oo/CK6GuuW4kmEm0kNbpPyTJGfe xXc3iZuYJfG99k98lp9ntuvLz0U4dW3TSegocTUQ2/WV0P7jSn6ZvGvGIsQuXI73yS93rZsr /vmmHbJRgnP9I0hhopMCd7enHHzSkh6mW0kJfbJWaLd6RMk9AoIQn+FyTE9++fk6IX7fq5tG 3VtqwqOVepKYZnmcsycJ85jkew8aQ9ir4J5S803PrsbmmO784jMRoVMOvunPEARBSG1ImpbU wc0CjTSPKeJtZOUNB27F89Zt3nkxpvMJgVOKhiBP4nRPiH0lUHDT/guWAdV80xD1ttanaX11 YH63n2zcutu68EGMtYP8XqEN+7dKBtzrocyfOU2t9cGaX66bL7t1806NWGKUBnfOfQ7c01t+ JjuFPhXha6RcLJGnkRwV9zHmF4SEPoHldgEAAPxu/bHDfbQzO81e/PuNB5Ry0I6F07b03sX6 XNrNXXHzuIxFIAaX5X1A+Pt1wsfNkm/UoqMUXL33gYNbPxcWFhYW3r1XzDUHRfvR1rt+6pe2 zn9OOiT5USeKoig6iqL119UPHp9bCHadsPAB05xbzoZvMOe+k7+7c9DdumBVYeGv53f49V4x 9Vx0/s1mFEVHZ2fqePYrLCIqKh1Sj4n08VbcIvz1XlH13Hqe0ig6i6IPrptL/8RdFnW3kt9t weQTRfs6XmSrCnPXtWXXHNr4uAtFUXSU3Fzn9eOPW9iDs+eH0265KNqPorXXzU3YVYuICO82 87v9ckHFP6fjwY1AKcHVUEU/WSsd2ljWtUj5vo4XWTyNXLftyGHfhlYa94HC7MxUa4Kq6k9f ceoSlg69eTMyx1Nhl/CmT9ZqhDZ281Q8i6KEO96qClu4ez9heVNgrn8U7Wh/HqAqLLyRXWKv 3FmPnOmpLMdjO3cJbxXTCUxsQ9HZGZQQ76360xZhfl+LHdVJbEDRZT3z+KX62icyVI7tZLfr 6+3HdP3qpuj5jsaSu4SF9+4/55k7PVkTr3L52FfCe+XOeT6a+9TzuATjYwKNPKab1ICi4/MV s9qeZagI79goeGhOWqWn1vG2oKcm081ol0CpdWs/O2aB7ajnvwyfxxkb8ex26+WA4OikZ/6S wqJrhfdYBBY2zL/VP42iJdeunJ8v+4mwsIx1pr8X35z7bCNTr2rilH84yt/Ok9aZ/I1kY06O p9sf2r4TltsFAAAAfoHfYbhP7kAwl8+cVFVyz6xcGAr3sRB6T1cbYX6h05bm5nYihdzb29WB b27B4dtJTDoTYVJ7e7nrgrZ19JBpCIvFpPa04QjsVUXxrfguCpPFXnOUyaD2EgnN8wuO4ght 9c2NuY4rXlB3LtyveNHdwbu8LKGjhz/mFthvM761o5PMpHW3tRFamgkdHYKhOJPF7O3E4eY7 1oLDtRGpLMaCKWLo5G6+dW2bm/GtHV0UhN3dxQYH6WMxKZ24VvawthDwbT1UFmtZc89Qe9o7 CAtWQ+XZ7883EtfWRSTzfVWARadSiAQcz+jgO0ksWndXGwG3cM1YhMViUrjHt5l9MrDogu/Y U8m8B6Wtu4dCplGI7c0tLc2Ezl4alYkgLDqT0tXGs/4sZ2nXLhL111lKl70WcStnT21EEpnK WQW3rbOHQqFTKV0EXEtLc1t3D3sCKRYToXS2t+IEGkkk0Rh8FXdzK57XgiPwD04fgtBJna1t OIGCOEI7sZeO9PEONJNB6cRxr0AcnkCk0kjE7g5CM46Ab++lsfrmzxwmk9HbiWuZL4vHEZpI rOuWi4T7TDq1pwvfzDvoCxrJ7RONTGxvbm6B5XYBAAD8bv3Bw/2amGsWKpvPXS0dRYdmFmyd GhsbZPEsdEpn9g+NTI4O0slUMpnePzIygc5MT04M0ulz64LSaIyBURSdQSfHBvtYnMVCmUMj 4+yFOmdQdGKkj86gcOvsH23IcHjDcD+7cWKoj0zm1EqhMfpG0Sluj2ZmZydG+uh07n7JzKGJ keHBQRaVTKGR+0Ynpmb4ax4f6WfSucVprMGxsQWrjc5MTYz2kWk81ZLJZObQ5KspFEVfNzjo xEg/wqma1j84NjG9nG5PjY8MMRdZEJWz3yUaSaXTBycnp2e5vZ2dnRzp6+MfndHR4dFBFm3h mrHoLCpwfMlkRv8o95sP882c4j0oNBZjcHR2dnSATqORqYy+oZEpFJ2dRSeHB/voPDXNLe1K 7xuZRNFZ9FfAtxYxhUpHBidmp8fYq+DSaIzB0dnZieE+Fp1CprEYg/PR/cTwCEIXbCTC18jp yYnRPjKVItCZhYMzNTE6wLuA8Dx6/9jUBP9lODGM8O6WyhoaGh6ZYB9+Wv/Q2OT8mTOLouPD CO8Zy+wffZS7SLg/Mzs7Mcyi0fnbudgRRFF0enZ2dIBOpcFyuwAAAMAv8LsL90nkjuIb8puk 9ML9breRfqtWtFfhUq7s2aHsllFeQ1m6OD9OuP9s2c8FAPhDo/fgXiZInzpv7hBVIrjaNAAA APBn8ocO93urInRs1LWUojv7UfQ3y+2ehzho6avaJpUPLfeTnHD/1rKfCwDwR0erCPK11BXT wpBQdHLp4gAAAAB4U7+LcJ+JIITy9IgIN1tbWzNzY/kja//53UFZSavr8Xd/rUlQBHQ3P7sf a+viaDvHzNRKS1fNIy2/rm1ZU9MghMrqbE8TI/Gtaw9IKukY2bpdjcooJCDwbjH4U5pbFNfH ae7CsrKy0lBTNfFPL6iCuXQAAAD8qf3hwv0BUtNDbIibm5ubm5uRwpFv9mzdtV8r1C29gdz3 q0yCslBb0bWkUDeuKwamrjGxD1oYy6plrG+2If1aqNa5I2I/HVU0cvNyc4/ENjBIv8r6qwCs cnOL4qYEcC8sMxMTM7fwa8VtS38aAAAAAG/D7yLcZyBI3a2rxsYyYnzUHe2uV/x3WtBeU5Jm JXZBfH7X51UvmiSWEsnL/upAXX5RqAFPH2RUTQMS6xDyrzWZCwCrWU9PW0m8nqSSxPwFIXFR zDb78cvOpT8KAAAA/KH94cJ9OqEsOURdnI+chrjHo1bKst+cX5nnccZ2Gjx7Vw9JLiMsL9lH UXSIMvPQw1hDbr4WqXPn9EIedRMGlv4oAH84MyjaXX7d1VGJ58oyiYy51/pbNwwAAAD4E/ld hPsAAAAAAAD8ifzhwn0AAAAAAADA2wfhPgAAAAAAAKsLhPsAAAAAAACAJUG4DwAAAAAAwOoC 4T4AAAAAAABgSRDuAwAAAAAAsLpAuA8AAAAAAABYEoT7AAAAAAAArC4Q7gMAAAAAAACWBOE+ AAAAAAAAqwuE+wAAAAAAAIAlQbgPAAAAAADA6gLhPgAAAAAAAGBJEO4DAAAAAACwukC4DwAA AAAAAFgShPsAAAAAAACsLhDuAwAAAAAAAJYE4T4AAAAAAACrC4T7AAAAAAAAgCVBuA8AAAAA AMDqAuE+AAAAAAAAYEkQ7gMAAAAAALC6QLgPAAAAAAAAWBKE+wAAAAAAAKwuEO4DAAAAAAAA lgThPgAAAAAAAKsLhPsAAAAAAACAJUG4DwAAAAAAwOoC4T4AAAAAAABgSRDuAwAAAAAAsLpA uA8AAAAAAABYEoT7AAAAAAAArC4Q7gMAAAAAAACWBOE+AAAAAAAAqwuE+wAAAAAAAIAlQbgP AAAAAADA6gLhPgAAAAAAAGBJEO4DAAAAAACwukC4DwAAAAAAAFgShPsAAAAAAACsLhDuAwAA AAAAAJYE4T4AAAAAAACrC4T7AAAAAAAAgCVBuA8AAAAAAMDqAuE+AAAAAAAAYEkQ7gMAAAAA ALC6QLgPAAAAAAAAWBKE+wAAAAAAAKwuEO4DAAAAAAAAlgThPgAAAAAAAKsLhPsAAAAAAACA JUG4DwAAAAAAwOoC4T4AAAAAAABgSRDuAwAAAAAAsLpAuA8AAAAAAABYEoT7AAAAAAAArC4Q 7gMAAAAAAACWBOE+AAAAAAAAqwuE+wAAAAAAAIAlQbgPAAAAAADA6gLhPgAAAAAAAGBJEO4D AAAAAACwukC4DwAAAAAAAFgShPsAAAAAAACsLhDuAwAAAAAAAJYE4T4AAAAAAACrC4T7AAAA AAAAgCVBuA8AAAAAAMDqAuE+AAAAAAAAYEkQ7oM/jT4WQu8ltnd0dpMozN+6MQAAAAAArwfh PgCLmB4fG+pnMfuHJtHp2d+6MQAAAAAAqwCE++BPg0ZEqnwMT5+7bBadXP9bNwYAAAAA4PUg 3AdgEb0FuV56Ej/p+jWg9LHfujEAAAAAAKvAHzrcb6/pSLdRkJY4zSEhc9om4/7z9t+6ZeBX QSW23vO6qCN/+qJ5UFA+TnAzrRMpc1Des/+cZmDsi9+geW/Vi6eFIdaSF8/ZZpe+7HwL9dF7 kJcJ3oaX1c2Dg+/g30KFCIIg7fUPEwNVTp8/y7kCL8hcsgyrJOPIb2kP4FdA7ya8jNfXVz5/ +vTp06cvKagH5pCoXb91q16rNi8/0OA0r0vGGkH3KTT4eg4ASC+h7o7LOVWZ03LWkVH3CL91 c8DyQLg/p/Z6hIOmBC+TsIgCwm/dLPBrweeHhhhLyKhdMUxp7+l7JbiZmI2xld+/Rc6xFqX+ vsP9genJB3FGGhqmkTH3Wt9OlfTKR4nOempGV1I7yP0Tb6PG8elJ3G13HSN5zuV3XkJCyyOt 6hnzbVQPfjW08uvxjsoSEhISEpISEo7Rjxrbf+smvVY/cazEXU/lIvcmf0FGwimvtIn2W7cM gFWhKcfHz0DiopalRUYna3jyt24OWKV+03C/o/x+WoSXrSB7Z3ffrBd1bdQ3q53Q/CA2XPLw MWUTTWOrOXZOVtH3nzV3v532v5m6O2nFxQ8q3kYw+wvRyd1PU92DPPhG2yux5EFdz3+vEb8m OqnrSZKzvczWI3JXtBbm90wKgstPDQmLT3tQ3vFfaM7LilvxoQtOb1sHF1u/7AcNHSsZdFov UpUSE+hua2toaiAtK35CWDwc+3jBY4zl6K4tunfd09bKylZDTVtq9xE1a51rL96kQp6as5N9 tY8dkTI1NZ+/Ah0c3SOz6qgdb3hxg18Tg9SJux0Y6GFnZaWieE5875ea4UTyag0FXzyOtLaX kTimbmVuOX+WuYf4pj+jMVi/ddvA4lpKs9ND5m6H3iml5Y0kBEGoxNbKRMerbra2trYugXHX ilsZrD6k/VFBUogn3w00MCKlpAZBuEe3s45QGO3oYG9ra2sbmJpS0sj+cfujpKQQV+7nIvNL arjP9dsfLtian1t2Nzsgq4bBXN6ZI1jVPBevgPgyZhtpRWPE6EVwt5MySyve+F0EShe+IsHG +/JeMXUnk8S6N6wN/Jf9PsL9URKjARvh5ublJigQ8/ARbuDNah9D0YZi60u6Kppyxk5ckXnY 6t630/4309fe+KIg8yEFHfov/q1NenYbG8M31H6xmVk1f5yotedpXqq9lPyZA9861rZQRgU3 9zfXF2dei8i4/98YdhartzTNzc13wentFngz+zFhhYPeW/3sVoybm4Orq7a+4vEdF5ysY5+9 SSsnBiik+xFh/p5uZiZWKuJyl85tcXpBoL2FRx8TA93dRXaXpBS0ta7MX37OTk6BqY9a8G94 cYNfGdJ4r/CGr5OTub2t1O6PL9iklNb+1k16DSa9KTtF9vA5DQsdy/mzzMXNKbGivgv5rdsG FjdM66y96Rbg4+bm5nY14datFyz2z7srs3Ki3Nzc3Ny9fEIL8G30MXSY2FOTE+7m5sm9e/p7 ++VWIcPcW8j0BIq/kxUf5Obm5uYf7ZfbjAxPoCg6TKytyQnmfi48LflRJ7cNC7fmV43XZYXl 1jb1LO/2JFgVj7h7zfXUlQ4T0lhbXYUt7Vy65FKI5WkZTrLayrJ7PepIyIJn3gCgKPobh/st t276aZzZ8bXI39d+d+TYEbF5ZyTENF2v3Xn5RiE85cG9G5Zin0u4FXe8XNlf17+y2/YqXl5X Y2r/e3ukdrfd87qofVFM7MiuXV9//t7fhL79RmidhJPLzeercoRW6HmEspG51SLh/n9b+e0o e/W9274V/YfId8f2c8/vs2KnNC0DMXnPW5b9iIHShRR6WGpdFBOTVdPW9o212SIVfffNwv32 R8mJjvJiYhJiYjZRHvK6nr5vK9x/iXFy0T6307K4k0R/KxWC/7rSgnhnuS81I1dtuN97M1Bf TfG8fUwDQocw/3fieU6w96XtOzZ89M6GH8QdMm897UIQhNTWcMdZ/NzWD9Z/uXmHrI0NpoHO ZCFNWfGu+nJiYj8dPvC98P9+tO5L4TU7TsraRhIQRt98dfjy+kRj8bPbN3zwr39+fvyMRfLL HoTVhzRlubnqSx3aveWbT94R2nLigP61m/ebEIRG7W15lp8RaaOsIcu5J4sdkL5ioyGlr6a4 WTd9ud/5aMp0dVU/uH3Tho/WbP7h5Mnjc1UeO3NeXM4q9eajDkLv8seIjEdKLaW0Q2Iyni3/ w4vJNrZzD4Jw/3fn9xHuDxC6H/nrim/f9P6nX2/Ze0Cc65yapXP8/Wb6G1Q+xUAHYvR/lLLw vf3gTer51bQWpsXrSzvUouQFEfSvB38nNMRIXPz0cfGDG4X//ckXnwlvPiF/2r1iAEWn/3ut +HUxqjDp9uKLh/v/VSQS7qb72TNHNry7YdP3Ww/ynd96NhHJ5S0kFF32Iwbc7fygK+LiUhLn dcOuW8taRri/Wbg/Tm/H39DRunRBXNzY0cw4Ie7K2wr3BzprSozW79ZPSX+y4nwL/Lbor0aT DDdd9l614f6r+rpC91P/Oe19vwc/9Fs3BvwySFddodMpyR1rPt24Zc9l7+BiMvvnTTk+TtKb v/18zaf7ZJVCq2q6hlGksaXgqra4uKS4+P5vRNd9JvTRZzu/FT3hXEXCc25RU+Po0wgf83O7 Nn/y4Xsb3j3uU4xDBidRpPFewVXVs6fFdn/+r/Wbd26Xd3dIrUPRWRQdIjVV3Y3xcNI6x7kl n5DRUta4km52RFg2KqOCuLzuNBYWeF88tX/jmo82btl7+PhclWfFxQ/LGQeE5LbgV/YgtwMT Gxak4fJgRR9eoCmrPNYcwn3wM37zaXkq7mPcZESUQps7mud/ROlsydBap+GUHPOQxuApyqD0 dLfjeBBaO4i9DITVx1Ooj4VQiJ1tBFzZ9Rvuut/vMr/xpLZmrng7gUhhckuzWExqbzuhFc+p EI/DdXZT6bw75dnv/FYmjUbqasXh8Dgcrr27lyJQfAlMOpXUgSPgcUnGF+3snK4W83Sorauz lyZQvo/FpBAJbQROGwm4ThKV/kYzTtDr0jNc1Hd+ejE6QnrXSU0N39yn3E4waCRiVysOT2jt JLEovURiO2ffuNYuEmku+OhDEDqZ2N5OwBHaO7vITFpPe/v8UOLxhNZu2oI3Zxk0ErGTgOPt cHtnLxVBOIeESaeQOnB4PK61i0Qi9VK4x7u1g7jIKrh9LCalizs47DZXhS0I9+kUvqoWWVCX 72TAt3V09DJYfX0M8nz3VzrsDfduhMh+JhXexk3gSW1ImrbUXkkZh/isBYd7GTorm27Z7JR5 03Cfzy1r9zcN99kjiW/F4/L8tC2UT8tH4mob5q7Ato7uXgbSx3PB9rGY9F7umYPDE3Ct3SQa g3+gaeTuzva5o0Cm0ZlMam/v/JnU3kNb5iXI10jea7+Hxlh2TVwMam+X4OndxXd6I0wag9SB x+N5trL6EEpPR1vr3Pnb0U1jzb03zFd4bnNrN40+t5nbhbaurs7u7g4cDo/DtffQqBQy52xv 76FRGQjCpDF6O/B4PK61q5tMIlPmCi/eSD5Lhfucmhdv5MrMH27ufZFEErhQOPst9DBX1ZVW C8rH4ZrnS3cJlv6Fu+3p7mzlPX6Eju5u/jsFk0bunbtBkcmkXjKR965CXvky3XQyT1XsW1Bn J4nRx3upICyEc6q0trd1U/v6+hjkrq52Ag6Hw7e2dZL75u64LDqDQmzD4/HzXWAxGZQufBsB h8MR2jq7SXzXIJPJ6O3C47m/YXir4qDODc78Vs7ZvsILp7MiM8vh7C7jjIJnnVQGgiBIH4tB 72lLNTtm6hwc8oC/NIve+eJh6Jl3T5o6KZ4/pS0lp55MpTF5B6cLQeLNfvhm8z9Et5254lRC IrP62D14eTsqQGGzRDSlupVdE66xLNJ4h9A3km6hudxH67XRamqH17638eAKwn0EQZDGtGRP 88NiPiV05nyS39lam+K6930Zxzs3n7CHpw9B6OSutna+u0QHkUTle/jJpFJ6OlvrKnC5+meV PK7GFvIUbu3ooSz85cVkUHrauHczfGtrJ5ne3dFNovDUnG1s5x5kHF9NIXIKtnUQSa+/9sGq 8PsI91EURftQFGOxS909uvApz09r4694W+oa54xMoihn3dOZqckxhMqgUXkwBsYmJ2f4q5wY HR1gUjteUIuMxY8ZO8UW1nCK9w2PvpriKTo1PoT00XkrZPYNjAr87cuzX2bfwOir2Wl0cghh 0GlUKpXRxxxc3p/Ks7OzrwaZfQxq5c3oQFVxk2Lqy875ndMYVGRsckqgP+jE6MAAk7eNAwOj bzRryswgceSRscRWVVtjRQMrjW0Xgisn0ZG5gZ6ZnhwbYlDpVCpzYHR4ZGxsgDtANGZ//yhn AKcnxobYG/uGJ0dHhoZ4hpKODA2PCzwv4NbMqY9KRYYnpzg1zg0OnUpj9vcPj8+OIUw6+3jT 6K9ZBXdihG9wmAOjxLIF4f7M1FJVzQqcDIyBsfHJmZkJnu4zBwZHlx3FT09OFJhsNfVM4Evg nyckGCjuOmoZg4yxpgUP9y81M4U2h9o6v2m4z4dQ8OJNw33uSDaV3w4/+/eLvo+ynvIcn/Ep gQt2epzvzKHSkf7h8Sm+IlNTE0MIlUqbPwoz05MTQwwGnUqlUhl9g0PLTqsED/fctT8oeO0v x/T05OgQg8pzf6JRaf0jU9PcvszOouOD/Sw6/9aJ8ZF+1vx5hwyPz103fIU5YzM8f1lxu0Bj MJDRUYROp7NHY2xqdpRzfxocesVTFY3F7B+emB0dYNDpr2skn6XC/dc18tWbPCucmuQcbnYT GX39YyjfhcLZbwP2boTxt1ssU5414+ZL0/rHplZwWU2NTwyxeDtCozOZw5NTM9w7xezszPgg g0Wn0lj9/cPjM/PjzL6rDE+iMytbpnt6kqeq+W4MjL9a8LuNe6r0jYxYrIhVAAAgAElEQVRN TE9PjI72zw0+a3BsbHJ+cCZHBvuYdCqVxmAxhyenZ2YnRvr7mezDzRwYn+apeBZFx0f6Wby/ YbhV8QzOq/nBYQ2OjU1OT02MDs6d7SxkaGy5F870+BA+Wk7PIdgPS+Bcv1Njg7UZPlcNpQxu o7RhntKzs+jkSImnnL62zCkTV+c9H10IanncKXCOlef6KR/+vw/+88kP6jfxNbRJ9uaJkf5b uhuu+GYkv2TXNDk58uSG6blTYkoXr5ZzPkx/kpKos1Xo4w//eipkueE+iqLoYFv/Y/vjh+yj 7jWS5nuDorhc23OGOnYOhZzhmZoYHeznu1wYzL7hcRTlHpCZqZlXg310Gu1plL+nq4JFFt9Z wRpYcJrNoujk2GAf792MNTgyMDgyPMBTc1NWeaz5HveXXb3Uvrn/RdFptP6R6ek/zHN98IZW Y7jfRyNS7lmoydlYBd3lfc3saaqH7SkRHpt/OGfi9xTp5c0VKF1Ihr78sS0i//nww/f+/be/ vfOhkJAQu/iWn7YaZBKIlPmi3d2tWL8zm/du4FS4TkTkol1u2VP+JlaluNmemttqf6v8Kb7g brDqbhGRtSIiIqftPTECxZfQUpoVLivy1eciH73zz3fffe/9NTwd+lHlkl+xQHlyR0uG3rdH v+O0cZPIxahb5W80K3pVop290pEfrfKaWiPMT5xR1Qm+zh3ol3dCDFW+F1m/ecfFqLabvoaG ZzZxGrhNPXx+0l46glQlGJ4+s0lk6/FLutfxxW6nT++eG8q1G7fssSoofiEw8czLOyGGl7/n PYI/nlC+moUgnCiu+VFGmIzIF5+JbFMPjwoNyrA+ydnzOdOohavgktub0nU2H5kfnPWbd8hF d6S4LAj3nyTxViWxyIK6RCIu10fsK3YPvtgnKRlQ3UVmvEww0D+9SURERGT9NyJy0fmVy359 eZFwn8VEKJ3tKRbGZrYK/iXLrZBrlYb7XV3N2d4nN+5aL/Lx+/9+51//+OcHIsLC7JH/5kcp q8BqhMoTTtG6mp94HT+5a/3cwfn0K5G9tlEP6lr56rx7w17+hIiIyIZvReRjC6oIOGzAVeWt 7E+ccSrIrFl2IzubsryOf8HZrYjIBhEReee7T5ddE9cLbICu0lbe0/vgKfXAHATh5mtNJS+D pb9ct5Znay8duekmeeAHERERkS+/3i5tW0yq711YWEREROTTr7fvtS1+NLe5q7Mpy/OnDTvX ixzS1FQyN5cWEVkrInLW+W5WckKq+Qn2R846382qQZCmkheBUl+uWyuyXcs6LuxGqrkU+/Yl IiIickiwkXyWCvcbi+dq5jRy0469tsWlDSt4V5mjIN7m4nGecTykFRQskPY2Fr8IlPri87Ui a95751///ue/PlgjIiI8X1pTsPQvc8fF5uJe3uP37QUbW0wDb5GGoqQAKZHP14ps176WEOaX ZMpp5vYLNgk3G15X9VIq4nmqEhEREfny4EXZkGcUvi8j9CAIxkV8/x4REZHtZ/ab55JpzBex WponvhYREfny+wMKCeRnbQiCIEhnZV2a0ZHPP10vIvKtlK3dzYbu5mcY9fX7N4uIiHx78KJd yDPebzk0ND/zV1//Gecuz66qRmAymDtOVrJ7eLbW5vloKmwRERH5UkREwb2k5vkye8yiU1qr 74XIiOoGFefVIgiCUNvqKt0PS5uFhN2uF3zo2Vn5ItVyz7snbXIfYRKsrNUvbDPKo/A9amWH +/Im508qGSh9JxP6kMZgfx1NINzvrMzIcDi93SAtrxzP+2CeQerszPPwsdB8e+E+i9nb0H1L X0o3IiaL/RSBgiAV0epHTnzNe6jP6YXfeshbVXNOhofCTmEhkY///Y9/vff+h7z/Rdgh45CU 3iiw705CbarbwU+3rZsrtHHHD4o3HllfsAhP4qk529jOPUjVOiD1ys5PP2EXPHJOL+wW7wRH YPX5vYf7E4Q0jK+NuNL1BhTlvH3dT2zIVRfdt1l03npR0YNm2biXffxVvkhMsTgpKiIsuuad f/z9nfc+XCPE+YRMSArfl9xbC69qKn0vyuOkrFXiQ/76kK66XHXRvZtERUVPylknPRyloA0+ Goe2bRIVFf1B7rSbQPElzM7MPHAVk90rKvTRB+//6x/vrBEVFpnf+eZ9azVzG4j9Ah+pvWFh doK3jZbWSS+WtVMBfe01OcrvHjW4jinNzAs3ld2m5NHAmYOeRW7J8j4o+v160ZOWmODrt7JM 93D2vPmUjnZi23w1vbW5XqZ7RD9Zu1Y2rOlmlK/XJe5QblO+GniPxL9bFrkly+ug6PfrOaW+ +fQzrbCmbk6UMjM99cDlhPQe0c2ndLSDi6ey1E7s2cTe846j2n4N6MLMuTbBzJRncMSs0oJi FoT7fe1TWWrHd389V9UiC+rOomhrgY8auwefrP10r8WtO/V9rOc5GSZ7OFXbp9Ytd6gXD/cn RkaeZ9710xLSvrXcKSC4Vmm4P4OihDteKgpbRYX/s+aDf/zln+//5+O5K3DDZ+uOW97uaOSf LqUn39NdYSv3EG5X1Q8p5p/hvb212l9VVPRrUVHRUzaOmLqRnvrnngf2b1knKiq6T9HR+/FK GpnveZl3t6Kipy4531x2TVzMnvqbHgdEv1vHqfDbdV/oRhLI3ZwiU6/QEocrkrv4t9YUXzO6 ICoqKrpWVPQHteCiEvLCwvNjoxYcOrd5BkUJt92V5beKfnfokHp6uvrOnbtERfdfcvbJxY+l qxza8ZUo+5+PUXTqFVpsf0Vyl+g3Z8QMQ2rH0i0O7Ziv97t1X+hGtVG6F+3TkuH+1PhczfyN DL9PWflAoq24Sj8VUdGv5iv87rCMPhal8L6YPzWOFtsbnN8lKvzxmg/e+b//e/cjofn76HeH N+pj26nLf42/tbDST5K3I1/sOSUW2MS7dMfk2FCx3YHzu0S/ETcyCr07dPPygW0b2beyPaeM gprQhct8/CIMHE9VoqKiomvXffmDzd37zQK/C6oLow0kRUVFP/tCVD7m1tNextO0ZMO5wT/j cCujAUVRFJ1+heJjXBSPbBUV/WLvmVNBTb3Iq+poPYNjoqKiX6z78pTtvV6eiidRtCha79xR no6fcbiV2ci/Z8Ldch9Jnq0M4vNk1x9Fv/lcVFT0jIpHZtkyezw7OzM5zCryU3ZxcvWfz9i7 85z9XKy0o58hAs9ypsdRfIyt+GUNi5iUlw/umX63QSkuu0pger3yXD97jU2n/YMkPz/hEny/ hX0KCoT70+ND+GhpHdtAz6xm3gfz069GRvAPW4IlPleMeUvh/iyKTo42xEUE+mt6cp4iEJ+k OhjwXS4HflIIyEdR7v/YhjoHK13kdm7+SuiD999775/vfMxT+NsfzpkHN6MDfA/3p1AUl+so J7uFW+6sU6SFXUKYOU/NTVnlsea77Mvue52XO8S+trZu/PZKXA9T4Pc0+NNajeE+Qu9Gyp1U tb3coh5wpovBYf2vOlto2QVhuAIDPfUuiSnapXdyp6Vl0pCW0pL8bEyEnb2m5JebFOxjEuLY xbPzsx/jOC9ft9cUZjicVLWOC4qery/pOsbniuYlDVP/9Ns8eWl3U/WTgrj4KGf5ry+YWihp 6CnLXTJ2wGCSMBgHbQ23wPjbywlXKZ24l0WYjDSMg+wx5ctqBsE8HcI+uM+XqXQ0lqUEa0ie 13a5Gh4/38Y4H0NJRQ1X//TylWa6FTddNNVOyBvmdXZTm/Od5C6rGmtEVc5v7W198Tg/zM5Z aqOkuuXhSzZmLtwx97iioKJsYB54ux5hMRFiw+MCjPNl84v7zqg7HJC39gmOYRe7ER9jf/n4 RRWngIwKTiMr4q942JmZevH0N8LTx0xLSsE8tKy3mYQgCELubHlxOybD7NDpM2f3/qSspG3v i8EkYzAYByUNKRUpi8RibgrZ3vA4OUhD8ry2q//c4MRdv+ZkKCkhtvXT78/p84X7xKaWygIM JgmD8dE9ekTdZOGCunQ6BV9TkBltcPTIseP7NEPuPe+mM1m9DY+T7WVP7/5izUnbGOzzVuKy p4pfJNxna7sRYGZ2+XJI8Wtz1aWs0nCfTiPjnt3JyE3HeOtLKIj9cNwck5DEPt5Z2KLK2m6E 88Zta9XdFJvzxxQtfEPmzhzMjTiMnZKcrLl94r0qbp1tjU9K7lzzDXO6uOG8g7WSnLaSuoqZ FwaTgMEYa6r5hyY9WebDLm4j5yTGY7wN1BQ0zENyVraccFmsnpudpZk3z+kd7uFlqiWjZMVd QJjc3lt7KyPdROrb7386ZeaUXotHGCykufqGmdahnd9tlVALLXrcyiAxOIWLMtJvcuq7fi3K VumorHlESnHjXBfy06P0Dp0+tHPnOT0Tv4TkFGMNCakzBxUu6zn4JcakeMucl/fySn6C5+z3 pLLMyfOGRnomfpjkFHYj3b1MlSQV1O1ySPWLrJn7s+F++8P71711Lpq4JyYncBoZG2mrdFTG IjKlWDCDXBq9G3kR56mvpKXv4BjC6XeAu5mmlpaNdWoDlZNJk9t7a++lp93EBGjJn5E8fNbI D4Nhdwhz+9HD2hUtqdH6tLI4j+f4Yfzt9HW0tHjX5iW1N9bmhacZ7z9+SnzfT5dV9B3n9msn ryypLmePuY8gyw6Gm7MTPRyN9R39MJhUzq3Rz9lYWeKsQ25lA+eoMBCk+WnhrbxwSwtTtS3n rcLUzl5QNLT2CMFgQqKizM+LR+VUEroQBKERe1vKbqfdTLeTVDbWOq5pbikhfVbLPSgqARPu 4OJor+jxYO73YNuDkgQHDWl5bfekqLlDGBsXZa8nflbDK5c9W8784FRVFufFepk5yG2VcAxT vnhBScPawgeDiYvCGJ2/HJiLebrsFZfpZHzzAxPDC7becQ+qe140FQQqHFV2SyutXLAiR091 do7DqQ/3umDKmlrxGYk+2if3akVU0QicJ/Vz4f5lWztb53AT2YMnjfKodUQEEQz326qzg93O n1BKJTzvXPBlg676xppKbAWeyVr+u+yLhPvcqXWi06oRBEEQJoIQ6x7evpPJc5IFWJqoa2rb R91smL8xkvEt1SW5N6IwXlL7xLQMrAJ4SucUVTW18K5G3na/KM5S9YKEvGVy+LW5I3gtwkb3 7IGdIqd0gzKKOCWzjQ0uHvt07wUJbefklFQMBoMJc3U3NlbSCcUymKtiGSKwmN97uI8Sc9Oj vM7rZfejKPuV0sHW8tIYUwmjoISUTOycNCzW2eiivFXAPb4lcpFO4stH2Mzr2CDZ/Ttl1awC 4uc/gK0gEOnckXmeoOXp5uEchuWK9/WzNFQx8EluR1nzf/hPjPT3VmNL7kbayenpS19yCNKR OKxsdS0xAYuN9vN1vGLGW3hJs7OztKbSyhJstIvllTP7LwZhb3A6dLcE+6y3f4Tzh/v47Ezb HW99Y0MrK19uJ+J9LC0NTQx8CtpRdEVRErnrRYK+6KcaUVWPu2ltRVH+Sqe+tiltIbNflXw1 NtjTfP9WvN4PeupKp7Xc5Yz9uLsOcrNUlTmvn/K4p28QHUV6m6vSQoNk1yppm51UdzN2CeeU DHMyNFDXNfS9y2kk+Xleloecigs2KW2+UEZyXqCRmqK+G6byKYM9ODO0xkcVETq2l09uO375 /Hlj9+upKVgsNtojXFdq0zGflFba/Awv4zPTrfmeekaGVtZ+7MG5hcVG+ljoKB7cuf+HvXzh /sTwTE/1o+ICLDbO30JT+aeFC+rOougQuaX6XqiFyfnv//dHy7giArl/4lVfb1N+uOkP/7Pm BxWj0HsLn7ssafFwH0XR4ReNhR4/fmaU1kxa4Zw1qzTcn0XRIXLz0yf3sCmRfqb7/3ZML8wj ln2882/nP6ojD3OSqZmpiZprV4wNr5i4RXCvwVAHF31jJavEMm7gNTzEwj29lVsQoSWtY3nx krG/tuJPqq4JyelYrJ+Pt4+pzb0OFF3Ol1m4jeSK8/YyN1Q3CcB0oCtYTri3OjPDQ1HNFZuS zjm9k3ICjC4r6HMXEJ6ZRmkNteWhjprnDm84cSms5jlrbBTto9ZiEo1Offa3DeI2yWnPqXNj P1e4mKeJ2BAHXX1jG9vkl3NdaKoqDDYxO7dp7R4pVZfEmFQ/bzsNyX0XL0iZeCbdTI2ztje3 Vra91zEzPUFtqC0PdbTUF9uraGUgZeybFJOKxWKx2PTEnADDy/LSZtGPShZZM/dnw/0x2nhz oqumlWtgzHX+RuoZ29qyw9TlopXfj3fUv6xjGoK9mcWuLykxxvmKlKx+ZOWzzvnIfmYapTY8 LyvCJvn6m8mu/0LRKS4Fwy5e+ODOc9Lw+PKX1BiiMHHlvKOdGh/hqHJC1iWHszbvzPQktf5+ WaiGudKp7cdVpKRNPZPTMFgsNsIlSFtm62n/jB7Wspfx7W8m3Is0kDb1ZVeFxWKx2NzsLG99 SRWb8Ov3eY9KH6XteXl6bIa//A5FFws1dStNTWVzfyw2B4t1MDMJC054TkZRdHYaHWxvfPKw MMI+0FJyi02wrYy8moatfcB1bHp8VqD2BbvbD17SURRFx6hjTQlO6oqGtkEBc4cwD4sN9zTR NLQM5syWwx4cRkt5XlZauPp2bSsLpSuW2peUNdywmEws1tfMwzfEgbfwL8ZqS7rh4WCkh6mY nhjrzgu1tLbxSi7oHhYoNv1quDtZSUrOzCS8lDLSTnrmcGGHjPO18loWb6nyXD8nnYO6N3DX VY/uNQgoKOhAUcFwf/TVcF2S4hGzgOxM3IJb3PjAZHdNSS2R1Lf8+dwWCfdRFJ2bWkfN+f78 v0dYxIbnvNd0Umik4xUZeYvoaiaR3e/J4UlmY2XR3YJYCwNtjRMKHjyl75aUvSQMoBOcJx+j 5JGGOAfVs2rG/p5Rc+cOFhvmYawg/r3Y6fMuWSg6N5pNWffdxd//5qd9F639IxOxWCw27Xqm n7HiRfdrFbi3MK8/+P1bheE+hdr99K6zgp7zjfgiPIIgCJOKEO5Gu1s7eV+7Wcab2uCbqlMj LXU0LTLyq9sElydtybsVbL5rn/Otth7iwt0SKsswV3X0jSKLiNyZ/ZlUBH8HE2pt7hR2FSPw ancXEZfrtHf3WQkJeQOngNg7TxGEgSAv8zFFRSVlK4qSlpxzv+dlXlbIFemLhu43azjLCzOp Pfg7Ia66ynrOYbErWo23o8zXQU/lgrL/XTxCYyIdt+xML6ue0YqtRhBO2tFVlZtj+O2ug4rn XW6m87yu/vJ2dLCZqoGpc1g1QmYgCII053oFq+7dctxAMay4smXuINBJXVXJLvbq8uZ+N9Lq EYROQp6m+jiYOIelF/COa3dtbWGku42Buuf9Ss6ivqRWJFH+wr6D285b2qaX49nvFb68fc1M V+WyeRgBIbPzPXxhUYKdtNwV97Tn9e3swaFQup/lBzvqHl2/V0JzsTn3aQhSFqEsaW61MNyf 016aGu1prmPu6pNWTaIyXubHBDsa6Jg5e2KekqgrmbLlteE+8jDZ3s5M0TWV54sLy7NKw32u x9EmLtqSahikZ9Ee4svvxbnLXFQyjyqpxc8ffVov8iQx0lBNzcbf4x7/i9CdFY2ZBtu3HZKU 1DZwuZFQWI8gNAR5gk2+U/yw7k3XpWaQEdxtD+kfVYx9g8qW+VlaD1KV7Glr7BKRVcjb5O7n z+6Eu9lcUfd8WN3ISfxoCFJ5K8LW3sDawS+7qIXMaLmT6mJhbmhpF5VZSEB+ZhVYWldTpd9P R8TNneIecfpbE6pgcPmSrENmIYHEYOV5nN1/5qSucVwFgdHJwvnrSNm4hRW8RBAE6UaQ61Zn j4sfUDLyybzH2RGx5tmdAGezS+fVs/KfdS543/5nwv3255mR4XYOJlH3XtIYnCNM7W6vvOFg Y2Thn3j3yfKOCpnUVpZvK62laeueWFrJ/Wx7TUG4v7m2oppXdh2tU+BcehbqpG9+yTDhyQpS 9aW05Pt56stsl42qJdO5uyU2IQnSp3Yd2Clj55RdSWDfoGrzIgy11LTsolqXNfU/A0Fwj0Ic 3J39/bIrCTwTpHTWleWHWqqrWcQX1TUKHJXGdIzv5a3fH1dWMjcJuFVU3YYgncSO0uv+eVXN /Ecw19xcU3yr2CUtQy+vrIbmThpCfFZdejcm/RmdwUKQ9pp03wBD9UtmMVn19K65HpJ7O8qw /hrqikaesfeq+BP79tIUjN7WLQeVL+iauCYVFTUiCJWIVF6/kf/08Uq+q0FFkIpcM10TExMt BwtXTaVzJlkFdV0LKmqpyvKzEzv8o9vD8mYSgjSXprob7tt9LrKuqpVzWObDfZ9rSY/irxmc OSB5LeVpW7tguN9YmhJo9ZOcVx2t5Q1mRFvEIuE+uRdfctvqkLR56o17ba/9YNuDayayKvJa NoX81/4vm3O/BRsSZa2kYHo1tpSzci+5p630lp+azBZJ01C+cF9LTvw7KdurmTVzTy+I1Q+v uZtKKVg8pjf+kVbd+WP5nYf7TFxeQKi7p3lK69wPBnDPbl9zsXYOLSHTBjnB2xiK1t+Ltnd2 vBaThxOc1XakF621lz5tfzX92SKv4Y31oQ3pnvbmATcf8y2v29/SeD/W181BO7iBSBf4478l 18lA/eixswbmTk43S8l9LBRltTY8z08rIaODy4+Slpxzf3KQRL7vYKytbxua/6CFGyv3N9/H Btvo65g4PqSQl78s7Cjp8cMEnW8269x43EMaRUcIhUV+Cmu+dcxtoXC+AjE7M9MSJqkne+6Y bojXvVbOZ1mt1cXhltoXpH2KOxv7UBRFR3rqa+w2nTqlKOF4M/UZN9bofXor1d3QyNAqtBFl jKEo6VkpJsDSwSutAUU44zoxMNNbjAm1svZNT33Akw1VhSXonVr/vZxM+P1qxtAoiqKs1tac YOlvD3uWtTaxh2uUMl0XZKZ3xTbszsO5tZdnUZTRXIIJ1j5zav+W18y5T6zC+NqLLwz354z0 1len+2pr6znGP3rRibBan5XEOuhq69hde1Db3rfIB5by2nAf7e6oSdIRkY1t6upYQb3oqg33 uRi4ymTpv6tENT5YtIcjzIkXN8101Iy9kwue8wRiPU+qrrlZahspZjV1D4xzfz4ziTaHWGvJ HvtJ0cAy1C29gdY/jqI9+JdVBVk1lBWsXiAAaSoJM9c+c9agBCULpotL6Xl6P9nfytkvoxHl Nnmif7L7XkqQhZVvZnop75vs3fgnSVG2pnpGMXn1fVRKc11elJ+RiZ5bZE5T38+vE9F9191Z X03MMJM63196RWKq6dGt8pEptX2U0fqSaNNL3x34yelhDWNkFCnMCPNSUbr2AkXHURRFK2/H GF/YdEzWIDKzfn5Hr5DJ7sLkQHVdk6iwzFaW4A5/Jtwf6e+qKnLUNw/MLcRReL9+0v0kO8nX 0d4zrpSKjrxmup/FzKAooynDK8DMyMAr+yGF89lhpLfybpC2mpJNFLaudZD/Q7Ty6hT773e4 3ulkruT6/FnDPS+e+h3ZdsojvhjHt9uKwAhNsS93KSlGP3qJjIyhKMpoabzpL7tDzPtZz8LQ +Gch3eVZaa72V6IfNbCrQlEURacnx/H5IVcdHAJv3H0hcFSG2ocrrE8dE5O8oGvqnnL9QQeK TqMorqKwrKyc/wi25JVdvSByVEZR1cYt4XF56yD6qm+i535i3gsCsR9Fh5GOR4X2sqp6vlFF hPmBnUFRekNhqJ+FyRWbhMdUdJTnCE6NDTYFnFSXljyhZGoVfj2rCR16haLdFc+rynOeLzh3 fhFiS25kiKaGfGiIv/ElHYvoiLsLT8LhV0NVNxSPKJjHRD6moOjQ2GCl/4ktKvY3kl7wHpby XD8nneM2N8fa7l2V1lHzdEuu6xQM9wfHBsv9j5/3xTwoHxTczRtZJNyfQVF6400rV3sPk4TX 3+OHu5qwgdo7Nmpjup4LPBf6BXPuDxFfVgfIqhnY+OU0vaRw9kurLwh2kVNSkOEL94vcL/xj +yWjqMdN3QMoiqKvWKOE235S4vZJD4tgVRSwOsJ9h/MfHNWLiotMY0tITHC/ckHTF1M+F5rT iEiRhcIlAzVjvzRBCdfj3BSOqATllNUIvO33s+E+5UFkisPFzYp+126kLqjTycjIRtsoBceX FnURcdlOe78+puEVXPB2lqRbMtyvy/AJMlM4H17XSRaMrVpuGtvY2GqGPFnmPlkI0n3fS1pZ RU8xaP5V/ZaboXqXpc4YB+MQ0vx+uqpyMwy3fXLENaqkXuDJRfsd/0R3HZnY7k4yC0GQ5lwv b7XjGy5E3O8kC+QDLQnaHt5XbbJJrB5Cd9R5KXVzDafoBaMdERtrfOiQa1rRy7mHLKRWJFH+ 7HFNdf+8Sp7aymK9Ak21XCsQ9nvNxILARDftk/51XQsGp8jtrLqW/srCfQRB2ktTEtx1xdSc rieleF6RM7D1DlzWVzP4vT7cr8nxdHfR+fOG+5SS0HgXnZ2WxUTygqcmZT4OVnaX7HO7eeeD 7qxoTNfbvn6Hll9x0YrnP5nHopGJNQV3b2XynosO0t9dMnR1u7vMqojNxIiz59QstV1iFpze 4dHRJgcOuGU9bOB/+lh2K9zWUlnPxPt6ire+qryVW2JRlWDFZCrpRWlWRg6nsuS4NF/ZQ4f0 LebyegRBkJpQBRefMI+7CIJQEeRxqIK4uW1Y/EtkLs1XcLzKG+4f2ievHhAmuKcmXF2cyjb9 +JLnC162/5lwvyzFzlhP/LJVWtrCe2iQtpSxa1hQ6bIiQwKhLvnK1qOuyY9LBd8Cb3uWF+oh cUwvl/RcYNPbDPfbGp+UFPB2I9LaSlN513GvQhKNe/iITUiC9LHD2nrhd3hnZHsU7uRvecXr CbKcOV1ICHLX55yMvp6l24IxTI6N9JHZrx12N+cl/++2xnSMu+KO78VtsikNP/+6fK65sdz5 Q6pXMQ2LPjR6nORoaq7mECu4lYYgLxK1xa1cImOq+T7QXpqSosJv/eUAACAASURBVLPz0+02 QaWNTb+8lz+vNMrb+MyevT8ePWUTXkXneRl/XtetjKt6P32r4P2E1kJBEATBF1+PUd/2uVIK tqZj/tbCCffT7nXX1ud4nVv7g+GNwuJO2oJwP8JWTDeGSpub+IvU3l1blJGezhn2rLz8+43M ZS+G0piW7Kq9e4eqRyrmxlxN1+KjHHTPnLa+9vQ+z2D11j96VJDFe6C9tMVULynqpq8g3G/N c7dyNbIOa0D4FiBAaAhSm+kamHb7AfcAZhsbWLioBpfylmt/lJxpd1oilv7s9U8fwG/r9xbu n9c2cAvM54j2s7Jx90rJ75kvRUhLvWq6/4Jr/iKiHfQtHNwSywXyuJ8N96cY+IGY4yc03KyD MAsqvHbtmu2+ff5leBr/ILbkOqkqn1O6FP/8rfR8yXB/qLux1Gizgv+9O02COcRAA7bQX3Gz 8eOmnuXOPjFKfBgbrnlY1KC0sWeYXVdLnsvRd/c7lRDq5zvMDvfl5fTUAh8KzH0wTm5q9d6t FvG8oGUCnQ/3t511vnqniSHQyNrMkqtKYrEDbczp0dKAGEfNA/rRC0b7dn6+i66uu8vVEu6y x1Vh10xUd0iHlXKCCRRltdanSn3rXtDynImiKDpBbuz2/1HW58GtOsHB6Sy5FqaxZ2XhPoqi 44wOQqKuop6DV9iNhCA3e0NV/eT23pUuQvj6cJ/e/RLrsEU2Af8nDfenqE30qFMHzTIzny4I lnofPkux+PxM3LPOPu479Oxw/5L4eVW/xDealWrOKKWlpaqI71bipGUodeBiGrrcqZJGH/iG O2gfMYxZcHrfys931tb28Ah+yH919PY0pXqcv2DmmXwtxNvb3EaX75sKbDMoSut4UVHKW1+8 jamGtpjStRcoyj5C9IrEXE8luXR2mzsrEj3tJZVcXqCMcRRFK28nhhnzhvvBunLfS5qUoVS+ K2MKRR9EWXr5+eQumHbqZ8L93raqG0ZfHLaIS4xf0O0UP0fPK1p6hQOU4V8+ofc0ij5LNDdy tonIEZwoZGxirDHl8nH78Pxcga8XvM1wf2iIha/Oz7/L6UZmXLa//I69lkH5dXy3wYrAEAO1 fZeiy3lmjaM1VifL7XQt7qxbXjtaHkR7mByTt8nPz1gwjPFWGvau/ler+H+3DbUPl1uf2nlA y+veYl+24K07r9RD+uPv1QPKqJ2L/KLoIVTdMNl+NrCMRBDcSq296eunrmJVgTJ47gTscF/u rJZ28P1lz1D2Ot1PahIMDx7+bvcuFcfkmkWeEYwTh1p8ZL89axn5sIKFoig6NTrw1GmvtJaL U2YLzyXDDvedM6cnhok5vopKWqaBST0jC8L9Sv/jalF3K+a+VzIzhVLrn5eX8A57eSO5d7mT pQ229ZfaHN91ycgtIpF77Ud4GmvYut/gnc7tFYvYVcu3u6RQd7MjH8pGdVQKzI21dLg/1PU0 3//4MZ8qMk7weSS1sfB2RgimYu7aR9GmrPuhBp/q3iUyuBf/1Gh/49Wf7KLupazoazbgD2Y1 hPtGJ/73H2vWrPlYSEhIaM1HH7zz4UciJ/xxDzjT9JA7kKRLYjvX//u9j4QWISoktEslpPCu QPj0s+F+S56Pl/Tnf/v3R2v+85/F6tx3VMEnE0F4coYuIu62096LQfkPK95Sz5cM98vjfAJN NF0qkN6F87Y8j/Tx9NZ0urO8XfbREPr9kEt75ORNzFM4a/QVJdjJKJ84JZ9A7aLMJQRdVbnZ 5nt3mGMLahYMXllsbqDJAdeK9l46giDNuV5B5rKcf/LB2np5eWvFvqB1tZQ77tm3SejdD9Ys NtqfCwnJ2mMr5mIIUiuSKK/sdD0Ai+PfLV+4XxZj5qp1TiUF6V4wU87ziAVz7s/5ReE+gjDb yzOSVD5b894/RSV9/PKa3iQ0fH24X53l7uqo9ecN95uz3WNcdNUwyGI52q1od08z3bhK3sS2 s6Ixz2a7dPS9sjftL4tB7a4vu2W+98CWtbxn5Af/+ts2uWWH+9T2+sd223d99brTe52QkJzT 3SrBiI5+Pz9G48Bf3//XX48aZ5WVCz7goNMoT6pLHGREP/2SU+t/1gh99O9/rJPXX3m4r2rt nrqgfx1tdTm226RCSioXPGD4mXA/L8LwzJ6/v/O+kNCi99DN5y1tMMt6CFPXXBchvdUiueTl wimAOspu5tgcuxBDElz24u2E++y1apMC9M7u+5CnDx+//77ItvXHve4uCPdlHZIj+H/lrCjc JyJIgvn+b7955/0PFxtDISGhbVqxCff5k9fGdEyk63GtNMqS3yXKNXf0CLhy/eVrNueEOXpY Xrn+ZLFZ158Fyzj5Rnrf4/the2lKlu1JyRhKVeuCD7yBxjT7CFdj7bTFh45eFBiqd+HTw3Zp 9U217F9ZJUm37c7+vy/1A4pftsw1nSfcRxBiU1Wqyn9OaF0NwzZW5QmE++G2JzUje2mt7N91 DYVP/c5/9omIkJCQ0Ifvvvfvf76/Ybd8AvV5+yIt+fk+JNuKr/9/73z0H+7lsOH7AwrXaZyq 2CsGF3vJyP647mOeQ/zhu//86vDKwv2cYK0reoq+Gb9k3vxsYzv3IJNEvlcTINxf/X5v4f6m b9778CNhYWFhIWHhj9/9+193a8VG8k7T8zQyVmfv//3rQ+HFbT2u7ne9lb/inw33R3oba+03 fbtB+P2PhBar8GthYbWQeiL/d9Vbcp3c/J2jC99Sz5cM91ltjakXNrvfaaoR/FYCijKeNua7 b5bCNC33dfLptspkK/0D289EUavnFqBsqn0QZrzxfyS9nxbi597SZIf7uvYBzrcWzMXNap1J vSDpXpBZw0TZ4b79ZjH7nMyFrSTcrY8zYIfsxBwHu3Of//29Na85gicu2iRz1y6oCsOEe8hG 4fh3yxfuM/FVKVJ/VY18eX9BvMWoWjDnPtfS4T6KzsxOj730P3Nh+0cf75aXDq3nXdV5uV4f 7tO6X+TabJaNx/1Jw/1h4otqh63aCYSHi2zF417EyWx1LiTQuFkfO9x3ivSIq3nDhs3Ozk6N IPVJFubiG3nPyDUfvPv5lpWE+12Z1pZnPv/Ha0/vk4pOmFKBz8zQxvuidb5b//lfd5w2iskX fHg0Mzs7NMjE+Cqf/OFj3ia+//7aA7tXHu67aB2yT0dR/v7NoGhThqVjoE9CsWDPfibcb2l6 7Hzuf/4huuY/i3Z7/c4TJwIaiaxxwc+91iSK5gea+/n48M2yxjb9aqQp6P+3d99xTWXr3sDn /dx73/fUe86cMwPjNMs0z4xl7L03FBGxIFIERBGQLiDSe1MREERAQAQMRUEIvYsFROklhIQS QnqyKFKk7vePhLAToohn5ogzz/e/Ya+stfbaO+D8srMeBfsQYqTUPH6xcH94qL/iaZqN0t/k F4j/Jsh9IvfJ3//vt4Ze08L9yEAfrQiJab5ruP8o9bLWtv/589/k5WX+KfrhgLFJvOQ7pI/6 8qnDvtNRGaUzbQ3flFoWZr7Stfo1V6GxtixMdaVrfgd/+pRZDyPueZ46mShR6kAY7tvdyPhF Pl0T66U8eeKwWjeqQ+Ze92NdVayQA4tWG9rHF1UJ/2TRWlm3tZT2n1H3IjZMfbFgMtzHsJcY Vh6ibaGvrX29StDdnaqPD/cfX96ldZ1YWimqtzuA5VifPfCzvLy8/Kf/lPvf//dff/jf7dYp 0iUH3uIcuossd339+byP//kp7vIpOBDxXY0O9lKzgq6qL8a/pz/958ef/OPjfQHvEO43VOde Pf6xZng75zU1M/Btkx+FWa51r+nCfVAN4T7AmwvhvrPKp0fcS54WNzY2NpYQoy7qLflMyX9a uK910ejKg0YZmhobya10FksqF5gp3Pc3VVpt+eDx81pZfZJbWjuZ+KeGfxvhPoeGytzPbPpm 3h//8pd/iGv0ffLxX//4py9XLjqbLN5T/tcI9w8aejpGP3zNFaTSWBzR699/uE8qT/W6sOzP +3Zs/XSlkUFg1rQ6vrPw+nCfGH7B8txhCPffQ7jfXp6WZLnt6xX67gm5pbgbMdJwnYHlO4b7 +w193O6UvuH2lg5in4RHWSv9fcHG7Qv+dMgl/a50Jd8n+XHmJxf/pOhRkS7utfpp431j5b1m F+dKuG+kq2gT0tgo83coidoh4zsZb/Iew/1OhO46K646csLRPg53DkU3b9gbbZD15P4vGu6r mdoEx8taw8bGxua2LoZUj7+zcL80xEh/zR//6//99R/yk5W5P/3HJ3/960f//aPWjZLJDz4k wn0+j8povWq8WUHfKtInVCrc97bctt+6iFUn/FYJl8XppDY1NTU2NjYmuXmba32vHdHUwX3D 7livO4c77iabtl1KqK1/IX4LNJNbGQJxV8yWqseumzdtPWV0hZCPu8RJruqWehDuA9k+tHBf 3dYnPoPBYDCoDEaO54HvNCymhfvO55foxzFkY3EFvf1Su3K8Rbi/2zwiNLNeVodMBkPQNzwq uaXEbyLcpxOTnJR++L//84e/z5MTFaCUl//073/57//zB4WrUUXtwla/RrjvZaWn6PXwNVeQ y+/un8qf3nO4PzA+WnXz2OJTW5f+tEVnhWZk3WSQ+g5eH+63kMtDVP947EYthPvTD/664f74 6CtyhKa68ikNx9hS3F348LaLh9Y7hvtuVvqHfUtfe3v3DEin9/zmgYQTP2848PM385W1rZyl K/nyXw0S7Lf9qGpwMzAb11P5zQDbCwfnSrjvf/RPyr4PX5TL/B3K5nL7RkbH3v5zsfcb7ldk h+prrd+jepNRRZ48B3IZNc1022bbwF833LfT3WB2k8Egy1xGLkJSexv9zsJ9Tl1h7NE/fPa3 P//1H5/Ki+rFfjbv4z/94Q+LNp++Fjv1CbxEuP/qZQ7B01Bju7Hvs+4YXXy4X3p513aHm9l5 wu8LTYxjQ90CLovBYDCq85uuHfz6iF9kPmVgtpt89VK6H17atcHMJ76wEv/O7xnEd9WR4nDp 1PHt2gH5DEb7ZJuqvLvXDn188iaE++A9mwvhPn7PfWYn5VFRvKuZyhnf+MeibXl4dNR05byy 8QW3hCdv7EvCm7flqbhz18tgrXJwYWvX2+0c8R7C/ZoEb38LNeVgmdvymF28aKsXMIv1QAix Okg5l1YrqRno24fES/B2s9XZtkTjWmG7sLBte1lKoumqz0+GpzySztlaMy7fdpfclsfw4HcG 91umpexT2/IwqB339dXUHexDC2fOZd8u3O/IvBLtcnbv5VrZ2/KcfedteZpK4lzcDDT1nBIy svKSfS1Nztsa+hNr3zU6fG24/8jX0fzCcYt40tvkMjJ94OE+My/wlrP+Kut8GRHwI29760vq l6Zty/PLhPvUF+mRngePGCcWl7TS8XdtqvUWM+tZh/u8LnJHst6xE47OEcVvW4u3NCz4krnW efcrDzJyH3g7nFazdI2JxSfrVbH3Ak136V7PqGRPvbFYVPTQVk3R0vbdw31FffPQOOlZNpJq IrRnvS1PS7qP8UWd0xcLEPNdqlFMRybXxBgv3eFy5+FDWdvyeCjtOPcrbcvT1YyyDLXOOTiG FUvU4q1PvOtjuflXDPe5CDXe0t1tbucfXD5z68lZ/VLh/pu25Yl5zbY8/+lwvyH52tlTxxS1 rMQFk4WFt29c81RZvOFc4I1s4ZY3EuE+QhyEGlOslFR1rA/pWuDCfUZDdnjI6R3bvMufkKZt AFQUeMPBYPG5BOZsLqH4HGQU1JVAo1ZnXN620+JG4v36VnxN3MJrZxwM3i3cL4m2PHnmyDmH ojfV6hCBcP/D9KGF++I998cwrLut4k7opYtuXnEZ4kAF5aYGOR7Z412CYW+7Dc2bt+Xpbusm 6hxS9Q0mSm8m83r/6XC/j1ZfbLL4pMxteerTsi+rv8O2PM3Jdm4GyrsNQtIkxD14YHlozTHb a7miwrbCbXkM7E2jpHdfGGI0ULyltuVZ/PPp0NvF0svcU5lUIN6Wpzbqlru1kkHSWxUBfotw f5hR33F54zHvwrRaWdvy6K1913C/h9uWG2O43dDuVvS9kuKkiJuXjLefjy3uQu+2RfNrw/2u khd3LL7afLWYwn3H9+oHHu4Lt+XZYpGUVD6tBGlXUUWc1XyZ2/L8AuH+4OgwKU5b0+na7QQy C7+bBSn9WqDeO23LUx0e6mqjYnzvbev60p81xjsfVjF3T8rLKIyNuWJpaXDRrxTjiW+FHupQ wflj+j7XHzTR8FWc2xJve9gpv3u4f0FrzZnLrRhfYpajGFYYauXp650yLeJ7Q7jf11mV7rv1 G7PklmezriErk3hbnpAUWdvyxJ36NbflaYq6c83upG3Siy5sqhZvX2v/E7t92+yCfsVwX1AR 5+128ojlI4z9lmVcf7FwH7ctj/SmLuxKwmu35fmPhvuooTrBS3nhNpOI27ck/2iFXziudcZE O7x2sqlEuI9h/KYHVzy0lJdeyAg+Pm8y3B8ZGaAXWu845xYd9mTaBkCsmu7o4ws1whJlfsgw 0znILqg7ZQzDOrKcrD3sfK5X0XowTLxfFbM6N/r4xxph7xDu00glQcbfLzZK7qya8d8xEO6D mcy1cB8hxGTRn2UEGtoY+wUSntQihBAHoTKivanVaSvLW1nluLqviEmhV96/7uofn1dTLVVR 980FdWlVZckBpiqqpz0IxBrJYrw1melRkdduZeELzP464b6KoYGx5V3xc+E1T9KjgjwCPO8+ o7O4CCFaVUrSNYvj6i4JFXSqOODjMFB5nK/paQOnwNDZVfKldTSnOa5bqGoTGfVYarGay1Kv mKz816FrT4obWQih9rKUpPM/LdisruGakFmGy7BqMuIDHC44XY4rFyV6jSmePtprv9p13iwk v5I02S2nC5XH+dibOQsr6PKYqDnjusU5g/POXkmPyfg4u6OhIz/SzSkytZIkGubtwn1Eysq9 ZXvspEVofidu2I6yODezfQvXv0tBXTZCZRlhjg5G5y2dIuLLEYuLUHVair+9qb6liTehoIsl XbT5LcgI93lM1JwZf0Hf0MbXVfpbAR309vxYVyc3W1u3G0nJby6Y/JbhfjUx9Zafra2Ti2fo /RpW67QvOkj4TxbUJZVmh7uqaujdLOxqFudhXAZqzoiz1De86OeWLbk4v1i43/A46bLlxp0X 8miVonE7Oltz77g4nt40/+CZWYf7wmK8AaZnDYzdfO89acHf3u11rbmRLo6RadXkFlHbjuaM gEArQyNrX++kx2TE5SNScYyDu6WxiX3YzdwWtjClK7lxx/ns0tPxLyZLuTLJz5/FOzud3bpk lZ75O4f7B3YqbtE09b2X1yJOA2nk5/fjvM6ftkjKqZpVQV3UVBIS5qJxQtsvrIhFnnolF6Hm ktiAiOh792dXUZfRRXmYZnP4jGXozew6/CtJD6PDXfTVtd2Sqn+dgrrCGrmnvJzjy8XjUovv 3PHQOqaotPRX3JYHIYQqUy+4mJ8xsL2T9Bwf0TK62sqJ/g7XCSWlUhV1f7Fwn1JB8L5sYXba K6+Ww5sqidzR9PS2/jktY/eb2VIX8D8f7lPvWeir6h41ja6Q/BCU017bFK68bbvhxZu59QhN C/cRQohSeNXhvOb2FSuUNi5WvCEM9xGjqbgo0uTQIV2/xKrnknvvdKR7eZtr/GrhPrX5eZzV 4n9Z3i7JFY3LROhJ6nU/s/0rlVReE+4rnLG+ki4ua0wtirkd4Hf1Vmo+BfEFCCHKs3g7N70T Svq3Uup5HeJLyKEjUnqMv2dIXEG+eLt/CPc/TB9suC/EbSq8GebiYueZO/nQNJ2SG3lDXfeo a0IOQyARnvAqihPj4hKLK6QeHH9zQd3hXoyRH2Ry1vRSUHixZDFeAZVRmuDqmlDKRJIpzS8e 7kcHaG7cFlBPFlXuFQgYpQmubr4xpZWtAgzDhnvpXXm2Jmftgu49b8anjV0VD6M8zuubXspn dM2iku8EhlFSHE4ZqhtYZUklAQPj49VByut0LwSHPuvBJsN9jWNK2w2CIvD7OvMp7fnhBvr6 4YWdVFxB3bX71FWdEjJf4IridlWUxF+xdpisoNvdWEa4Zn3KwOhGURWvbyrFmhjHKLlptxNi M19MDfMW4T42wByrvmJuaOYV8wQ/LP1ZWtQFxf0b362gLp3y/G64vbG+vnN4IYsqwDAeuTM3 1PGs/nmHW4lVbYzpr5iJ7HC/u6ku4ZrnWePjCXXt3fh5jGNYy7MH0TddXT39Q0OLmbyXr7++ bxnu81s6S6JdXV1dXQMJJSTym2Pr/2hBXe5wZayZvq7PnZJK/Mp2N9YS/D31TVQT6mjd0wrq /gLh/suRV2XXDuyyu/6AKBp3HMPI5anR7uoKR/a8S7iPoYbHcVestI1MbpbUCvqnbrvxUYyc lRqdEJ9TJV6D7sa8vFBnO/NLhiFFNYKXAxiiVd8neJ/XN/K8ktrYLLwvOY0DMUc3nroRXtIm /FRpYmyEW3433ktLRVFt+zuH+6Emh3/Ycdzk5r06NHn/D4+N0Mri7TzcIqMyyNO+ffOGcB97 yWl4fufoGZ1LPvG11fiCwVg3rTqXGBUWVsKSfur8TcYxjFNP8LhyycXmViULw8SvfMkhv4gz OKtlc+NBtfQN/EuF+4+vBjvbKDjkicd9SauqTHB2OLv9258tLv+K4T7GbXrwIFDrmLpPRDEf 90HOOIZxG3LjkgmpD6Qq6v5i4f5LAbUo0/a4jl0KsZaN//CS9jTihrOZsU1EMVNGQd3/ZLj/ sjElxV1j/mq3rA5+t+Qh9NDPw0hvr25Uo+gTNalwH3vZ/jAnzHTLxkOHf/qzir0w3MfGRwbZ j/3crEwuXU0pltx37xXtOenyzq/VQn+dcH8Uw+rjTU7ZXbwaNTUurenxvUDDU0dXfHw4WFa4 72xxWDOglI0NjmIYhr3sqKy4H+zpcyuL3MsZxDDsJb8lO91mp6Kab1AWlYq/hKi+MjsmPDQ2 pRHrF36SB+E+mMl7Dfe7GmoehV+20tj49+36NyJCUoof1VC6EEKIjVBOpL7hBaNLrmk5OS9o bC4fPY4MtzY4rm5mTyDcEZeii7we6Xz28EEd5/hHj1oREu6m/SI7Jy2JcMPe4ezhb3846RAe HUkgEAiEJHFXCCGE6PWlRf46Rw+dveAXLFHm1dPU7JSh1qWoXOF+KV0N1Y9yUgiRkaGOat9v PuPk5SdslpBMSHtaTaW/OSx9g8e3TAw1jyhqO00O7GhreHL/HgM179z2LuH/prfWPYwNPKNi 5B4dHCkusxhFsNdS0/dwT3g0i4yT1kh6Ghceorf1fxcoaDs53srJfdxAQ4iPUFf9o9Lse8Hu F06v+9sCJTunkMzHNdTGspQU4582HVBfe8TcwuXa1OJ4mJhe8rKInvrGQGOKZ9CZtT8rnF53 3MonIEzULCaSYK91wu7mDVx43ZTq7W2ip3HW3g9fgTP0ariF+o4DtgFFlbUIMdtI1RlhSZZb dqiZnXZLyH3SQEM8PiI9z8+4bnxK79BeDf/7SY8orXQuQtS6kshrp/doWEfhhg2309xx4Gf5 xRsV95pF3M+tpHB4XHp9VWl2CoFAIMQSCD4GO9YdPqJnHCB6SWpxTS2VhTidzObCrOQLJ5Z/ vXr9CU2/3NxKGofHp9eXlt40t9i/+q+f7NYLT0itaaXO4npTGp4V3nE1P7vpkw3nwn3EN1ls NMHnvK6atXNU9rSCyHXkGi/Vv//pk48++scmPRkhO5eFmh7mEe8TCATCLb8Qh6PfbDRyEXad lJ6SW0nl8KQDvwcXzRS++eijP/9t3lbDtPYXNOkumS1VlUUpornZH9XQ0tlnHCj6z+zyF6TZ fqLBYHVVPbyXdJ9A8DY6dHLf+l1WhOhYYXfErOLKZlxI11KWdtdun+bF24HhuNvbx0jnhLVL dI54ceh1Dx9m3SPc8gu2P7pog5Hr5FImJKeklVHbumb73Di1pij0iu5W5fPR/qKeQiNCzTW2 7V8//x8rdqufupyXV9XJlaxQOaPG+x4e5/U0DRz8CIR48e1943Kouca2/Zeul9bUIcRobXyW ct1PdeGiH3YqnL0cU1zVjLh81FSRG+6mvmXLkmVLtQOjs2soNBaqepDqa77rwFm3mNgoAoFA IEQEejlq7ziw6ZvPF+4+pH8lpvhZPaP5WWZSqOGWk9r6mj7ZaY9rubySQLXd2if1LSLz8qoa ubxI68N65/U9I/OeVnXSeIIoa7Wjh9buOKlpYH6ZECuaZUig1yUTdevgJ8xm4ePEjFZ6VV5y orDEqLezycnNn+0xjIoRFgtOzS553Ix4oktY+YToba20X80q5nqE+JzvEAg+Ntqqpy0DAjPf 9psMIhwaqgp3N7C0dvALJEy5YmdoamJsHVvL4vAnGzaTHj9ISiAQ/M+q7T+8TdH08uSy3897 WtY0q0K+CHVRUabLGbXTehc9xeP625w6rbRyxdKVXy/Xdbmd85Da2YkQg9pQ+SAk0XzjJlVL A6/k/LKmTsQVoKZnOekB59ROHzmoHfDg/tPW9tntR/QwJdDMVE1Hz4kQN3XrRETedDA4sF/X /V5qWTtCiMfu6qjIyExNJATbWBmoL99rHXNH1DqZmJ9f3cnji+5YBrWhMpeQmEAg2B0+oXn6 oFmQuFPiw+oqfF5PKci75amvauERGzdZBpYQHR5ie3LLWe+kVFGozEOoo7YkI+seIcL7gu2x n9edj7ki+pWbfO9Bflkrb3anK8JmdTVVEBNTEwnB1qoG6kr7rAmx8QRCTkU1mS4+GnJu44bt CltOuSalpBfU8zrZCKF2asPj3JibCd5HNs7fpKBt45eampubmpBgqvzDjmPaNq7JxLSC6jY+ n4saCvzPaC/53798vlghRBTuI0RrbySGndly1sLfY2phCAQCIdjN3NTUVO9aIXuWm/LQa4uL Y+0stQ4vERfUvZ9XUN7UKbGzH629Me2m3gpNw8vOV0UrVKFYDQAAIABJREFUTSDYGqiobP32 q5/Xbj3gkJZa1jb1NSZ2O6q86aKyV1XHynxynleNj55UPqxxKeSuuIJuS35OuK3uETV9j/ib 4ksYE0HwPqd5XOmsJ+HuM8Rh0BqLEtKclI5r6h2yik4rqG7jC7iI3vy8+MFVy4vHV649H+ef /LyG/JpPJcB79WGE+8PdfV2Pi4hWR7/drWHkejX7YfHz9h5RttJcee+6ywE9KyIxtYbO6B7G GJWUuw6KmzWtI2KiJIpg2lvrG5p6xmZMVt8dZDWTnuUR790mBhzfuOq4ro2/uH2BsKtJnUQP T1MjfWtfiTKvUQER1mc2K7rfpTAZGIYNd/fSa4qIxExiqP0JjdMnjaaq+uY9e9HMkn7k8a0x Kh/ctlH4brdVaORdIpFIJIZF3zyvvOLgwQuJOVXCqGxoYryF6GHg6nLZF3/O153crW21PDPe 6il40VL3T9ArSgs8DfZu3b3xpGFYHrGY1NU3NIxhr1AXvbogPT3NWXnh1gMnTrrcL3nR3j0+ Xh+kbHbq0LojFsdN/aaGjrwW7mKx1aOkZfK8heH+4WMaG1RtTFxC8JN0c/U8i9tEo6e5pPCa wcFDpu63705VMU5PI/oaG2lbXQjJqsSwiYlxTsPDpyHnrM5pbjofnVHc3NU3NIwhTnt1Ttj1 Cxu+0nC+caOgmcwaxLCh8TEy0V3dxsZTYlhHI709i9csX/zVicAbyRXNzO7BV6ins7qISMwk EonEyCtW2sdXbz4RQLxzj0gkEnNKX7zoeIlNTGB9baSKcG/DXevn/bDROuPuEwaze/gVonc+ jHlguX7BJ+v3mV6OfEHumMX1fvkSkZ89SHU/tEBZy9TYH3cFI328L9ictYx6iKsYjGEYho1h WGag9pZlH330h8+XLHGsap7+EQRqa69+KFq6G/rHThpoiLrOIBbUkpk90i8gZz5x3vLRRx99 9NGCgy4p6Z3S/Y0O9qCmosLcTCKRSLzpHGBy8OsTAWGx94lEIrGw/HHTW3+zRWQCw9ht1U9K iMS4UD/Ljf+z0zDYM0J42jkZmS8ovYPi7Ht89FVF2CkXV2/XEPzieHtbXtS3in44WWD2FaLT qguI6Q+IN84eVTPQNLk29RasILfM+nOIwbGRpgcuSiZm7naintKIRB8Hg1P7l/y4cumPmy9m JpQxWT1v9Qi+WHdTQd5Vg0OHzT3uEO6K55eWSvQxMjhlbROeW4Vh42Nj7PriFOcjKptXL9xm cT2rsqlvcAATsFuLU6+ZHv3qf749aOtw+2kDrRvr6RzKc9M8ds7SNyRa2NOD1BBbrTOHVi5f tuGn7ZbXs1409XGpjc9yAszttLZvuZgZXUCl8xsf33a22L79ZFBmygsmq6ckPcJNe7tZUObD F8z+nuEn6bdtjyzfefLQYSPP2HDRLJMepPrbapr4J5SLNtYaH8PY9VWPhTU/Y1PuWSh+ueOU pXeA8CbLzCqjvuSLLmH38GBu6DkVI2Mf9xv436G3gj0tzuuamsa3znYZMXZpfoSfhb5TIJF4 f7K7u5EhTtq7jW48ejZZFnZifLSvtby8JJsY63vV8viCRepOt+KFJ5RVUPqQ3DMw/PaFfDEM w7DGVIKnlYqmdSCRmCI88+sezro7FTZ9/+mCQ7qOMVmNnVwMGx8bYdcVPQ7SM9XX2WEek1VK Zg0MD2MCFrUqM/iq5ZZv1N1vhRW1UDizuic7O+qiXQ/tOn0xJiRm6tYhEkM8zfSMLK/654ri 4gFGQ0NZLjEpIunyiRV7zJx9IkVtM7MK61jsXtFSj4+NsOsKH+cTiTfsrxgf+kY9KPKu8JyI ucVPKxnYkDivH2AO1kc56Fi5XYu4TZwSaHfWysFLPC6GDfBpDVX5xLT7iSGnf1Y1dDYPJIp+ 5xALn1PYsztdkQkM6+tqKHuaS0wM9/M78e1us0jfKCKx6FlZM098NMvfxFBp5Z+3XQyPSXpU z+jswTBsaHSEVluYmx9hbaKksHK52qWMjOKysvz8QDsdNYXlahczMpMK6yic3kEMMasJofvk Pv3Tf60xEYX7wifoS8ItXS2tLlzF37TExNuhl02PHnN5UNrIeePMpb3id7Q/vpPgfXz5j8cN hQV1swqyH7WwB4dxn82OYVhHyU1DexNTIw/xmAF+9ucOr1y34uu/rDsXEZRFpXJxH8OwSrIv m5xWVNUMIgov4J0rjpc0Duw6bhH8jC/6SzTA6K+NsNM6cf5SoD/+EkZ4uJtraZx3uPIY6x7C BNQXL2Jsfc8f/l4r5HZaFZXTN4QN9Qva67ITwk4vO27kahlZUTb9oz3wO/New/2aqCDj/UvE deWWnjIOypx6rizHy01z/YI1ivt9y6h0LkIINWdm+Z9aJSc3b6oW3U/fLjEMJneIY25OJ6XM R2H/6vnTKxNKdCXEaEWJBqrbfpRot/SU6fWsGtwkA8/jJik2b6HcqguBuZXTH2h9a9UZgee1 cF2v13L3yZVq09TaFKS/eNG/8OOutpr1uE9jkmz2TI30g+JB89vC70BUR503Uvged/raZiHZ pWUpaTabjt2gxngaSR7VMQvJxj/715jiGe6kd/JGc67L3r2rJpf980Vyq62C8qqkJ/k0JsF6 t+RVWffjQb/MdoYwQm4sSgg8IrfwC9EklSxiyhGDiwjuR7asE3X842rrzLwqYfOOjuZUrz3f 4Ib9cbV1ZoTjKYN93031XB3pb7BPxhUUnVDQjRwy6qgg3Tff883X80WTUlK6XN7O4FbfMjDY 952wbzm51brB+TmzWPes245qu2SM+bWc3DF74pNnMl7SSKkPOPPdgsVycj8cNL9wZ9pu/10U RDijsnmxjF4Xrv9J6XI2jSkdxme52Z9YKye38NulyjbZNOkvuCBESr/ip/Ga5VFw8El4w6YQ MjW01F4TnsI0G/ecupyMEK44Q3t74z2PnQtXfC1uM19OTtUh4yl+1KqIc/p7vpve3effLl19 Maew5h2+UNFArvbX+2b+5CQXfrvs8MWczpvWSqpr5BZuOHz46rNO5uyf3n0cFWuxU/KibFh2 +GpOJ1MYm9Xnx/oflvvqc9Fq7NW5eg/ROeiui9LGNaKz/5ecanhWWQtCqL0sNdls5fwvPhN1 tXTvasNbnYXO+jt//k5u014dp1sNyc7b5//89eRRs7udjIfh+jv3fCe3cIPKEf8iOivWRWnj GrnFG1Ss/Z/RWDzhg/xXbsVaHJaT+1xO3LGO+X3EEF+V+vzKq4cXffW5nCzL9p2WaIzaW+sS 3cXTmLTfKSdZuorAW8twtjm2Gt/bYmUbqdq87U/vJ5qu/PoL+ekznN74LVXe1NPb/S3uHFyu Bl+973VyhdwCebkTLrkVLxCqy7l9RVnuy3mikY7Z3q1AnXwU73RgvXDGX3y/Yo1t/sO62eak TU/ueZqskPscd0ILlqw/cYshfqSaRa194rZ1+3LJhZaTk5OTW7Tp2LGACubkJx91Obf9lOXE Nw7e5jPXrhVKjlyXU+Gn/DWu9Rc/rFxzqeBRvfgDEhZCT0J1t+76dnp/i35YeexSAbN+lh+m IIQQaqNUE1w3f7HsK8kuD7gGplROP7pw6Qa1SNZzKkKoNDvK9JCcnHjGy5cvP3To0GefTf5g 0ebVqgGFbG4XQqg0LMp0x8Jlm9QkauQyEXocqrNlp9QZbTl7NqDwtfN9vcpQHR2pvharnLAn VEiE+wihDoRi7fetWTW50nJya/VvPQ7ysjDZLvfF4tVr7YsfN0guJdHeQmXlVLfL9e1uF03b O6u2vsxH64t5uF+Ri+Tk1NwKXwj3/OuoL4vV+mK18PCiLWtOBBZzeF3oxX0PbVXxv30U3a+n vn6LQPD+fBjhPr+q+b75Jnn5+cK6ct/t2qwbVYthouCorbg24Ii8vPxq8+Q04aOLgyys1ktv y7LvJCoOqljcKcY/VUrP8vVWXyqzruVUV2KV0Xcsdkk0+m7XFr2oWvE26/wqUrL5Jnn5r6d3 t1Rdzy9bqo7vrM6fSUr23Ci/dLLr79fu1U3BOiQeUJzAsMIoyyM7JcbVmPW4gtbxe9p71nwv 6mH+8nmbvVNa2AIM41elJpmtmur8+93bzkTXjo9XBim7BCd53JQ6umfbmWj8HvT9nbUv7Baf u9UUHeTtobYEP8kzV3Io06Yxmqy9axXuAn42T361hV9GjTBGGh8bLXDapbJKNMnPt/qktLAF 2IvCaDMVcceafldyuiYXpyXDS1tiWE2/S17XE01XTfXMr2xINN0o8wrKy3+/54z+bQo2MY6R b3lp71wimtTnqy0fZNQIeC/uJZqKT3/pXv2rt6VP6Q2o1BdXTsnLfytj2N2ql2KLZbxkHMMK IkyVd8jLz/95+zbfOhkp4YuISNMdMrr87HP51ZZXMmulnxulFlRcVpaX/0xefo3WlczcaY+V 9tPrKt03rvvxKxl9rlM76CFrmm8yhmH5wlOYZvGX889eJ9Fxz6eOYxg53V1TdQm+2R41+zj8 qLznSXeNV8q6evLLtK5ey3uXL1RgWF648aHJSc6Tl1+jdTU79HaYn7L8vC++WmNFzK5Ds+6V Rx4gaG35+Zup+c37Un6N1dXsOuEUR18N5NltUVohWo2vFugHk7toWEVumLGy+CV7LzrG12IY Nj4yRA7XUN82eft8/pX8seDkhOBEF9WV8v/6asGZYHJxsKu66k+4o08fVyS6nF8pP+/L+Wus M3Lq83LDjA/JL/hy/k7rjI56JHyQ36t8gGCxefkKeXHHC47faHkqviqjr7C8S0ZK4uMSvvh6 kURjbAzDmtNc1Y//JNFsvbqTl3QVgbfWkvPE5xC+twWr9krV5h0bHmgOO3lyq4z3lrAxTfC2 n3uKccvvxhrhbrP1GioOsQPlrmqrFn8rv1fDJeEhho0M9uVe3HhwhWikRXuuZtEE3VhF9g1D 8YyXaQdcL2TOPJ6El6/6y26qrdoieUL77FIT6qYa0VKdHI9JLrTwLvtq0Vqb7PxG0V+OkcG+ HJv1ij/LuHw/bj1qmIax8Z8ojgxiOTbnJFsv1wkMKcKfAq0szsFQxlvwc3n5tTqB+UWzPV0M E945KY6qR3+U7HKD5nG/RzKPKtinJdZjGMYZ6ImzXvuTeMZffvmlqqrqzz9P/uDzr+XXXrxe 2MTEMIzT0BOnsfanhQr2aZI1cjuextoZSt3jP2373ii9gzPrfztxnsbelupr4Zpv9/vnMtC0 rwCVZwSdU8KttKJpaGB68R0N+Z8Wyi8/HRwqtZTNGcUeB6eaL1Y8YE5okN77axjDsoP1FLZK zEBByyPpkXjUYD39LcLFmS+/1ja4iMTCOG3PopzWy3/3pby8vLz8Ru0Tlx9h4PftvYb7XAa9 ndI8VTqwtZ2O22iA3UlrJTeRKZRODl/4TCKPxaK3khsbm3DlBknN7V08vjiHE/B5nE4KhYxr Iq5rie9qsjVitrW2NEu0k5qG1CSnuiM1kjvobO6/UcWRy6K3t+K6Jrd2TtvAhMfn0dtIpOZ/ c1wOg9lBwRW7pFDaGRyEBAhxGe3tFBK+gGN7F4s6Ge4XVMo4in9MUxjua93hUSi4ZX/dJKWm 0djY2ERupnSy+AJhLsVjM+nURlKTaJLUDgYHCQSI2UltIYs6biZ3sCafrOTzecxOCgk3bDO5 g9VFa22nkKZ65nbJvoKiE6J3sXiIz+Ex2ykkYV3FxiYyldrJ4QsE3C7x6Tc1NpLb6Gzpus1v wmLQWltkjClZQFjycvO49DZSE6mxkURpl7EZPZ+HmG3UFpKMXknkZurUSuJmQaO1khsbSaRm ageLP/2ZVB6L3tn6muWh0DpnvZ/61ClMQ6a00iXrVPP5PGZnC6l56v0qo/wst6utjSKjvyZS M7mDPdvHbGVNkkRqpnaw+V0d1FZyI4lMpdI5fMHsntxHCCEOg9EhecFJ5GYqnT11ezPo1EbR TdZIprTRmYgvQAwalUwWnVJzY2sXi8NDCPE5TGZ7c9Nk68ZmCrm9i8+mtbU0kxrJlDZaF49J a2kSLV0zhdzO4As4XW0tFJLwFNh8gbBnEpnaQefQBAJhuJ/2jNFBxf0Wbaa0tTPR1Ony2Fw6 ldQk41eojMaIz+cyO8XTmLpxWO++ET+L1kElS6zitNq8k4sjY4azL+Qrwu1qa8O/syg0Op3O 7GxtbiQ1NrbS2BwuQlz8FSRRqR0MjvAKUsi4X1BszqzvSR6H2dnejP/T1khqJrd2CTiTv3AE fC6H1tLSLOOcSWQqlc4VTF4VLpvROXWbSWhpo0vXr+ayueKKsqJTIJM72Bye+BQECHG62lpk /dYhkcjUDraA9y5lQ/g8Lu4Gxi87kzv9qHA1uHyEEIfFaJe4gZubqVTcKZBayK10tkDARwhx uhjtLbjXvvGMWtraZFX3npH0ndPY2EiittKYXOlwn49wt4rob0oXh97Z0d7S2EQik2n4ZUcI TXsvNLfRpMsrI4S4PE5naxP+V67wjuVyRQvNYbQ2kUlSi8NldrZN/eKndNJn3OUJvA8fRrg/ Njwy0M3BlQ7kCPqHMWxceHR0aLiPx2Aw2GhgUPgY5sQYNtwr4LCYEhUHed39Q/j/1x0d7O3l s2TWtZzqSmy4vx83Bfw0JqYmiTgyu2PxBb2Dsy28hz//sZGBXg5DPFcmmysYwEbH8W0mMGyo v5vH+TfHHR+dGBBw2eKVYzE4vYMjY+MYNjY8OIDY0qc/Pt4YpOwSnBTyWNZR8eLgwv3sesll Z/EFfUPSkxwfnRgQcNiSF5Dd3Tt5VSYmJoZ6ODy21CSHh/oRb6rj3r6hscnFGRnsFUgO29vT 2yeas7DnN1xBBoPJFQj6R7GJCWzkZa+AI+6J3T04ODw+NjyAO30WV9A3i11GsNHR4T4Bg8GU MSyX39Mva6eMCQwbeol4HAaDweJwemXVIx1+2f+6s2F390nf31PvIwaDze8bHJr2QPP46Mhw L5st8x3D5nN7ZW7o8Qa4U5i22AyGoG8EX6daeAX5ku9X6cWRvAoSWPy+vumn9C6TZPP7Bl/2 v+zlTV79kfGZu5EyNjI+wJf+/cTu7hscmby9xyVub6bg5cjYKDY89HLq9mZwu3sGhjEMm5iY GHnJ53NwvfFeDgy8HOjhs0WvHXrZg1s63suBV6+GB3om7/3BoZGhoZeIx2AyGJzuwdGRcWG4 H1o1PsDmsPDvat7LkVfiqzIxgQ31IJ7sBZduLLyCPXye5P3D5vf0zjpdnzQy9KqXJzHktNq8 ExPj0ovz+sZve/VeDfTjbzM2n9fTP/6qh89mMidLIk9MjA91s4XlVxlMNpPbNzg6No4ND+Ku IEvQ93LW9+T4xPirl3y21AlJlWMdHezp4cl8ozLZ3YNDk3esxCQlsTg8NIiN4W/tiQlsqBtJ tp52CqOv+nte8xZkC/qG3uUt+Jo7h8Hm83pfyTw6uRpj4+P93WwW/nV8Pp+F/wG7u29oZAzD sLGR8X4+m8WUWknZZ8TiMNHg6Nis3/hjr/r7pfpispncvqGx8Wl9vRrsw73ZGSwuetk3ONTP Z7CYDJbgpfSdMzI4hH8vMLnc7oER3N/fyZUceingSv7K5fJ7p4p4v3opEIgPs7tfDo2MYWOj w/097Mk/T2wBv++d37HgN+K977kP5qL2yXC/pGmGlsJw/1Qsap9WnhAAMGdIbcEPAABgrvsw wn0wVwn33HcJTgp9NkNLcbifN4tH2gEA/3lSW/ADAAAAIhDuAymtVXl3Qy3U1Dd//dNBc11j W9vL0ZHSdV8RQjyEmkvvXvfW2XVo+8rlR20trG1tr6dKVN8FAMwF7XXU3EBnxyOblmzbe0DT 0NbJ1Svsfu204rQAAADmEgj3wbsa6GXXFgS72B5avENR9aC+q6tvkFtiPQtN31a5h15XkOxm dG7rJ6uVjU+ZuboGxkpU3wUAzAXjoxg5KyXKUl3lwLplhwxd3RxdAwmlzS29M78UAADA7wGE +0BK08M4b0e1vVN0nexwFXQncRGqTvU2NjmCa2kcfEvGxwAAgPeK/LTxzgXlg/sn36jKR9St g8QVdAEAAMxJEO6Dd9XDayu8ra+ocVhR5MQZJY+SVhmVgznNJbev6SpOOW1vEVkpo0sAwHs0 NoI9C71irT35Rj2oqHjaLaG8AipoAgAAwDAMwn0AAAAAAADmGgj3AQAAAAAAADOCcB8AAAAA AIC5BcJ9AAAAAAAAwIwg3AcAAAAAAGBugXAfAAAAAAAAMCMI9wEAAAAAAJhbINwHAAAAAAAA zAjCfQAAAAAAAOYWCPcBAAAAAAAAM4JwHwAAAAAAgLkFwn0AAAAAAADAjCDcBwAAAAAAYG6B cB8AAAAAAAAwIwj3AQAAAAAAmFsg3AcAAAAAAADMCMJ9AAAAAAAA5hYI9wEAAAAAAAAzgnAf AAAAAACAuQXCfQAAAAAAAMCMINwHAAAAAABgboFwHwAAAAAAADAjCPcBAAAAAACYWyDcBwAA AAAAAMwIwn0AAAAAAADmFgj3AQAAAAAAADN63+F+Z3V1XrSPra2dra3n7byC6k5aY0VBuK2z g62trWcwoeBR61Rb8hPi/SBbHFffkIRsMmLzpvdb8yQ9Ctc2KDo68n5Ookd8OZ3JnTzq5OQe klzVVZQSEXUZ1zTl+VPytP5ojbSCMHdnh8lWHq6edwvpzM7J4xwGrTze3d/d1jUkISHrCa6x q9+NRJmTbC0lEIJdxeN63k6JiiQ8uJOYTUZsvnjcBlpBmNvUuLZ2Tu6+96pqqax/e+kBAAAA AMAc9cGE+yN9GLMwKeSqr6urb1hiYgUPwzBKXnhMoKurq+/VkMRCJtY7Imo7iJh1Ca6Bvq6T PF1dg9NqOV0D0/sVCBilCa6uk20DAwMT6uoSAtMqXlAFuKMB8UUNTypflN4W9+kaGEPMo8ia KiWXGBM41c41Jv0FtQt3vOs5Me2mq+fVkOBCJrcqY7Kxp6tbSFodd/okB7rqa9MCxN35ht25 lfm0MCSksInLEDeemMAouekxAbhxXa/eLSpu7vm3lh0AAAAAAAAMw95/uN9aWhrnpLV7x/6f v1im5WB+hZDg72l5bKOiwp69m7ceNvLxzqQKG3Y1PEq+Zm2gsnkvzmH1M2b+KZmVrHamuEce QqTnBUG+Zqem2m5W0T6y58jpo59p3CG1MRF6TAyz11u3edW3q3SvxVme1zx1aNvevXv37t2z d+9GFQMv5/CighdUcY9MSnXVgxsRFsd2KSrsFHa4U1Fxt47lrcS0aiqFhRBCLBolx0v17O5v 1+w+dlDPearxho3792ucCiwt7+KI58jnsGgvsm+7nT2rijsZLV3FbfvUlfScHyM6RzQwpTg+ zuLYrgOT4+7du/eA0l49l8txRc+baP+RKwQAAAAAAP7TPphw/xUfo8R4Gmipblqy5ZDqPs+M 50Siv+kxnSN7FPfsVVbR1iV0tQmGMQwb7ma0FMc7a25WVVZQnHJQ3y0qvrSjHeE7RdyOgowI a83NiqK2e46oKhx3tlo/74R/WC4FwxjMlgR3RcUdC5cdN3Wz8r1sfXLbZIc7j+gYm/oXEp93 9fQPC7sbHeztIRUVB5gZ6xzZKR5520kjj9DYF83tL0WjNmdcDzi9dvfGlT/oRoReMhA13rtX ccXqo473k+u43bgpDrKan90LcNM/OHUqJzUPaZ5R/XKxZVLDc55o4InupuchVmbauHEVFQ/q WNtcTy9t5Pz6lwcAAAAAAPzGve9wX4jRiu5oaNnortu8fd9Kxf2+ZVQ6F9VEBflfM/XORQI+ 4tJLg85csL5kGl2De1lZyT2bk4t+UPaqyq/jTj4Zz0Aoxn7vfh29K+HitjVRgef3L/lp+xLD RHKHKGNvKEgNUFx0UHHpRtPQ61nCZ/U5CJVFmezfs+Oosn0ynYv4AoS4jKpETxf13d8d8E2n 0kWBOu05OdVKYdEqDbf7ydVsrnhG6Xaemhu++GHHInHjsjsJFse+mn/St6GtYfJ5fHYH6ZHj 2g1qdnbRT8UvzfY4prHu+7UHzX3LURcXIcRlVyUn+V3YdsA3q61LHOQzWpsS9BdvOmJqH/mQ OTUwAAAAAAD47fhgwn2xZ6GEa1pLNHWO/lN+u1lyWhUf41c15/tv0rlPakPY2FDXk7txl1Q2 edWSmOLH2rsx7L7L3pVq58JuPB4aneqrPDfM6uSPx51qMdHz8vwqUrL5Jnn5+SrX7hS3idtl WR4yObxk11lLvaiWyZ/Rq9K8Tbet/NvhsKdk3sg4ho2P9LZVFFouW73H2jOtaupR/ZYoX20V FTWnqxUDIxg2Ifphdp2fwjff/PjPtVYewsaobfyeztYfDuuHZZeNTU2xI8XR3khjrU2e+Cet RTHXVOZ/Nm+z+f3magGGYeNjve29BTZqx9yvp1fjvyJQGWVpqqG03fpB3wg2NvFvrjsAAAAA APhdm0Ph/v41a9ZruPjnUyidHD5fgLgMOp3e3slGnE5U5nvewtfrZn47A59nc9jM+rpygq22 W1Lxi8mtdIThvraFTcQDcVsug95OaW5uaW5n8vgC4c8aCu76Kv7jU0XXiIwqOkv40YAAIQ6j nZIZ6OplZuhXjuhchGqir9lYqen4p1M66Xy+KJ/nc3mdDZQ061OqtpeCsqc+cEi3s1FSWLLb JpjS2SFszGFUpcf5qGy5mE15PpnQC8P9Q2bXfFIbxS9ldVJbySQypb2Tg/gChFB15jUf93MO oZROmnhchAR8HrONVOBvGxwWE4P/pAMAAAAAAPxWfIjhfrjBrs+XHrHOYdQyBgaHx7Cx4ZGh Po5gYGR0HKNnp0b7q1smc3qHR8bGJ18zjmEDPdzH8QHh4eHZuK10ynPDXHVWmt8exnjCtmPD IwOIw2AweH39uE8BsixX7z2spRtQLOif3PoHGx0e7G179jD48CrfHFK1AMME1U1p7uuWW0Q/ bm4fHJ568Uh/b11cpIfdYZ3oOgwbFP6wJfuFh/L4e/WVAAANJElEQVR//ZeibUFtrbDx+OhE Py/RUMU7Iikdl9B3pDh62xooB9aLfzI61N/HYzAYnO6BkeFxDMP4zKYc7w3Hg5/W1ePHxbDh /m5qwb0UHzufOow1+G+uOwAAAAAA+F2bQ+G+2ll789Ci+q5pR5lt6N7ZQzs2/mv5JgVpu3fv 2vj9F5uMQnMLRLvz8xBqeh7n5ap/At/utNOt6CcSvTYUxPuryG9xKMmqZEoNWJPgHXpJ99x9 1M5CKM/d29lZy7uQhhAf34jPRLQUD3VTF7/YfPEP0+1crS4ccc4gISTeY78+PyXkxEbrDEpF x+RLOSza86zgi5qnlHdMTVHd5XLCI9LUAHkxdpoHvv5+hYLC3mmnvXXpdxtVL1xIwDUHAAAA AAC/FR9iuB/nabLtQkpTNzY4Ou1oTWSUleJni9YpybBjzdJtKvpXEuni1ohTl/HAVR/fSO2M hWcJxuyT6DXLcoXeBR/vXCQ1Wh+tvsTkB/PYhqJ2DGsvqr9t+oMOsbyj55VUu4HaoqgAiyOO aRgm2nKnJbsmWPeLY3cLWgXiCzAxPp5lqXI5IuEBDfdSJulhvK/VyR24KZobeWdSMWxylPa2 yiDNv3y2cfuundPOed+W9Vs3bd8RTCVzpCcFAAAAAADA25tD4b624y3fB02yj8ao792nuFFJ x1oGG2trz8jc6upO3EtaH+bGBbpOtTljaHT+vG1IcDa5a7KybUNBfODRz48EkQobpQdsSvWO cNLVjEVtTITS7b09PXVDK6dNi43Qo5BTxl5+kUTxz9LtpjeeHu4LVRNvRnjjzuPMWaPzTi6R Wc8Q4iKEUHqE9SnFb7cctra2kHXaTkF3CaWtCAAAAAAA/OZ8iOF+wnVXletNso+Wh4RZHv5s /UlH2Xxv3C18xsW17+9i16QEOjq6ihpcsLU1OqPv6pdc24CrbJtlucLCPSykXHq0fnp9pd0P BrcacikYRsmtv2X4g11lA2N63d6OckK425EL8RgmEP6gJXt6Y5nhPoZh/JaKkkjcSVy4cMno goFbYiETCTAMw1oozy8f/mjx4TPGxrLO2dUvKCifwRGXGwYAAAAAAGD2PoRwn92OcsxU1S9Z B+ZQZRx+G00Po2wuHDuwzjC1qoMlrFbbUBAfcOSzfd7P82o5Uq1rEr1DL+meuzfzk/ue057c f/twX9rjW1f0TiiomPqTUBcPIfSY4GJpPPWfAAAAAADg9+K3Fu43x93xtdmmfacLw4bfpfce fmtWjNq327RDb5fQxDvZZFmuMLIP8H8ovbVNH63+odST+7oZ5R090kMP1gmf3H+Ae3L/7cN9 aYzKxkirFfM22BU01/ZjGMboqIkznLfBU/SfAAAAAAAA/PI+hHAfMRFK9Dp8xvJCMKGNzkRI ID7C5/JZNCqZ0tHFFj6RL+DzuXRqeydD/IS+ELcmMcnPePU2zwyKqChuQ8Hdq4c+XX4uMq6I hG/MZXTkh3r6Wp73Fe25H+VvY6WmF5hN57L54pF5fGZzB9FG+7itbWAWfs/9twj3eXweo4Pc TmdxJArichmFIZYOusp6SaiDhRBCZXccvAyVNEJa6tr4nKkJChDiMDqobW0dHdIVdfl8HotO Jbc0k0iU9jY6+7ULDgAAAAAA5rDfWriPVRZH+xhtMA1hoc6RUYlte0YH+pBAgPoGJn86NtTX 39eDBiRajffRBh+aqhx0vHqvUrx/T5bl6pNnLKzi6/GNx0cGmXVPw46u9cslVfExjF/V9MBt 7TLL2BftXSPjuC5fDTTeve1hp6wdVYvbc/8twv0JDHs10NPb2zMgsaXO+DC3qfTm/j+eCasq bMcwDENtVfd0Pj59ueBBzcCAxAcLY8ODfT18LrdvZFSiou4Eho0O9SEBh8Vic1locGQUP2EA AAAAAACkfRDhvgAhZifB1kbl6OaTPkkITe2RT3tBSb+4f/E2w4CcbDJCCHE6KWW++3WdwoOz yfguymLs7TW3rb9Y0ERjCx/AbyhIvbrv6+XLPlmpfw3fuCba1NbGSv96qaiwLZdRleDpa66u 4FdOpYvDdFJrU4jhD+vOut1LqmZNRexvFe43tTaFGy457f/gUTm+XXXU1TM6hw7a3mIipgAh hDiM/MxI/YPzl6uHUB41i9txECqLMt6voWlmIV1Rt4PWkuaj8P2ahZ99tlFb3TfvtQsOAAAA AADmsN9cuD881EAsdTj693m6/jXtbfgjlGg/PXV1Pb/oyYq69Gy/G962Z6Ip+FaorTJF8y87 TaLjn7LEQX6W5aGTmz9ffkQH31hQnZbmrrrKuuBFR+/wGIaNDfe2VRRYLFdxT0+tFuC6LLxt qWug5nT1Wf8whoki9rcN9wtvW7u42MQU4afIr2pMtFv9x/3eZZTmUQzDsPFRTj/vuvmmFerm 8TFV+Kb0qgfetge3bfWpI0tU1J3AsJYsH131ZfPm/WvDF3opdR3dr1lPAAAAAAAAMOy9h/s1 mRFBxgoKe3YprPjiq++X/2vNVIFZk+sFmfjsmvr82b1AH0styXq6B5X2aFtEJKRWUShMhBDi 0MiPHNdu37jqR1xXCgoKCifOnfO4nfWCxuaKNtdpKHhw/chKHd8wk3Pq+MK2W48Y2AQkP8IV 9mW2VBXHX7E4vung/n3iZorKR/Wc7yY/oQrHZdEoud5q5/Z896/Fi79ao3rCPKakg9GFHmeE OZ5Zv2bp5x9/s3anssPdhEetCNVT6y+ry32zbtVGiQLBW49om/tdL3iOK8ZLayPlp0c4mSgr qUy126ugsOmIgZdH9KNHDVLVh9s7SEkOa/6+4E8fffS98gHHjF/tugEAAAAAgF/RhxLu97Go JZ5KZ9SUlLYsW7X0h8+WThWY1bMPjnyBa9rP6a7LTvM30VU/JllP9+R59xsxFaS2yWK5HSmO Lmo/z8N1paSkpHRMXcnE/+5Daheaelw+y1LF3sHO2NUdX9h231FdNeuQwqbuvqExYbPRwd7u psJgqxO6R/fhu9SxCgjNmhqXnBkcqLd++/IFf/5u63YN/9hHLVyMwWxJ9FBS2rnosx+Xr9p+ zts7k45hExiWFXL28K75yyQKBO87euK4pXNaRXW3+OINT0x0NpREB1qd05E4md1HdU3MAwrx k8QwDMMmMKzpvv1hBfmPPvr7ov+jEl9JxX8aAQAAAAAAgLT3HO43P05LviarXKy19bV7FY+b JVt3VlXlRHpaW9tMtXJxdI0t6GTSJpvwWPTmjMBAL7vp5WfvSpafbSh4IHygPjk+TKKw7bV7 6U/IkgMjWsOzvFBrB1txIzt756DEyi4KS9SA09VRdsflsovwoJdzUGZlF5uFqh89iBCfn1tU Xn51J0IdXR15d1wcXKTPOOBW+hOpR/ERYrI6n2cEOHpKnlDAvefT5ijZ2CcyPHNaZwAAAAAA 4EPwoYT7gwJG7V1Hf08ZBWOvRqVlt0i2HunFGPmEID/J5pGpzyl0XKvupsKCO77Ty88G5jPY vRK72wgfqL9V+FyisO3VqNAcqYExDMNasm9EXZWY4J2C+ibck/H0Z2mpIeKDqQX1Xd0Yn99V Eu/oKJyw5w0C4RlX+Hz9s7SoEEcp/v6hOVM7/IhMYBi3seCu1An5R6fLmiOusdc1p7u1DIF0 OQEAAAAAAADw5sa2PO+DONx/9uY6twAAAAAAAPxnfSjh/vslDPdTOt73PAAAAAAAAHhPfp/h PpvZ2fYkKdpbebVR7NOs5yRya0cHgzvz6wAAAAAAAPj1Qbj/RqOjIy8Ri3X33H6nK2FRz1ks zvTitAAAAAAAAPz2/T7D/ZxYV83d//z4b3/4nz//Q+4Tuc8WHzQzuw2b2AAAAAAAgDkBwv03 amuvCdCdN2/Bn//wv3/7+GO5eQt/3rbZW6o4LQAAAAAAAL99v89wn9rwrCAzfkpy9iN8BV0A AAAAAADeIwj336i/v5v8LC0tK02EmDO9OC0AAAAAAAC/fb/PcB8AAAAAAIC5C8J9AAAAAAAA wIwg3AcAAAAAAGBugXAfAAAAAAAAMCMI9wEAAAAAAJhbINwHAAAAAAAAzAjCfQAAAAAAAOYW CPcBAAAAAAAAM4JwHwAAAAAAgLkFwn0AAAAAAADAjCDcBwAAAAAAYG6BcB8AAAAAAAAwIwj3 AQAAAAAAmFsg3AcAAAAAAADMCMJ9AAAAAAAA5hYI9wEAAAAAAAAzgnAfAAAAAACAuQXCfQAA AAAAAMCMINwHAAAAAABgboFwHwAAAAAAADAjCPcBAAAAAACYWyDcBwAAAAAAAMwIwn0AAAAA AADmFgj3AQAAAAAAADOCcB8AAAAAAIC5BcJ9AAAAAAAAwIwg3AcAAAAAAGBugXAfAAAAAAAA MCMI9wEAAAAAAJhbINwHAAAAAAAAzAjCfQAAAAAAAOYWCPcBAAAAAAAAM4JwHwAAAAAAgLkF wn0AAAAAAADAjCDcBwAAAAAAYG6BcB8AAAAAAAAwo4/e9wQAAAAAAAAAAAAAAAAAADA7/x9G nySnYX7H5wAAAABJRU5ErkJggg== --------------AC3046D55907173764757B95-- --------------1F7217D1FDC8B5BF17F110C2-- From nobody Tue Jul 12 00:56:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E24812D731 for ; Tue, 12 Jul 2016 00:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.787 X-Spam-Level: X-Spam-Status: No, score=-14.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvC9bfcZaewm for ; Tue, 12 Jul 2016 00:56:44 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE3912B062 for ; Tue, 12 Jul 2016 00:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2208; q=dns/txt; s=iport; t=1468310203; x=1469519803; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=eRq3+fD2FLY+4mgjb4EgwPBgt9Ye03GHq1Y3jt9s2MU=; b=K6DpHe+h8b8ZdHkbw9sXrGwMC7C1Aiy/mX5I3qWCgfNfRYwmzdVsn5nO h+JKMJpYx8pfn5cbH6YquO908MG0u080gNNQ58EQJNxga96tPebTvTMhj 8T/4Lf9jff9bnLZb9Uh7WlZAGdhlWVFTg1gM5Jt9KyqOgrVqp3Dszj/FY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtEwB4oYRX/xbLJq1chBQqRgy7AiKFd?= =?us-ascii?q?gIogVQBAQEBAQFmJ4RUCQEFAQE2NgsQC0YnMBMGAgEBBYVpgj4OvlkBAQEBAQE?= =?us-ascii?q?EAQEBAQEBIYYqgXgIgk2ECYNJgkoBBJNdhT2GD4hFgWpOhAqDC4VgiDOHX1SDc?= =?us-ascii?q?zoyAYdvgTUBAQU?= X-IronPort-AV: E=Sophos;i="5.28,350,1464652800"; d="scan'208";a="636679825" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2016 07:56:42 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6C7ufnt017041 for ; Tue, 12 Jul 2016 07:56:41 GMT References: <20160708044045.18829.26837.idtracker@ietfa.amsl.com> Cc: netconf@ietf.org From: Benoit Claise Message-ID: Date: Tue, 12 Jul 2016 09:56:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160708044045.18829.26837.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-15.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 07:56:45 -0000 One more point. the grouping tree is not exactly right in the draft. pyang -f tree --tree-print-groupings ietf-restconf@2016-07-07.yang module: ietf-restconf groupings: errors +---- errors +---- error* +---- error-type enumeration +---- error-tag string +---- error-app-tag? string +---- error-path? instance-identifier +---- error-message? string +---- error-info? restconf +---- restconf +---- data +---- operations +--ro yang-library-version string Regards, B. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration of the IETF. > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-15.txt > Pages : 125 > Date : 2016-07-07 > > Abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastore concepts defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netconf-restconf-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-15 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > . > From nobody Tue Jul 12 07:39:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03E712DF07 for ; Tue, 12 Jul 2016 07:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5WpoSiNmgam for ; Tue, 12 Jul 2016 07:39:28 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6DE12DF63 for ; Tue, 12 Jul 2016 06:49:39 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-02v.sys.comcast.net with SMTP id My2tbjGBvBAXOMy4Bb1SAi; Tue, 12 Jul 2016 13:49:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1468331379; bh=ZC/0uw6UKtpwEeyz1atzrqu4zLQLECRt2JPvqmz8m+c=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=q0QFot0vTXFNwwemySXiQyCi1rpxrSp15c1AxI2ThJukPBERFsV6NYkOjuLlL2DHF z5WMafv6Wx3oKpg8sszFSz260dNlFPiaKBJdh0K8fegqb9e2fMnwK2ERRVYyUnqVk5 qtcmHWZJgzlaaI2mnHraYZzVRElrmIynhy2lruwUqIf4oe0ietv/XwMygUL79zvFHB 4FQMV+lTvUOUBZWPP1qM7W3T9PDVEHRGHgkG+wsbP3j57io64vf542PBU7O4hr42hC o79d1l8RfqyGBcYWVpAn2UhpzbCBdvSSm7BXMYiwa0mVlnVFKYg2Lu6Ov2UFi6L33S tQ6cf9K2+kyFg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by comcast with SMTP id My49brq78IePNMy4AbpEqB; Tue, 12 Jul 2016 13:49:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6CDnaYb007082; Tue, 12 Jul 2016 09:49:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6CDnaMP007079; Tue, 12 Jul 2016 09:49:36 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Andy Bierman In-Reply-To: (andy@yumaworks.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 12 Jul 2016 09:49:35 -0400 Message-ID: <87oa632cgg.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfP//nIzlIOhzol5G3jOT6WxvV3WxFQ8mH29jaSEd1sI1hrMXiArumD3qXgSXZvqFEBg3K6RA064B4C5EtO9S4LzuSKhac/JRgXCaoyJ268XLu4oBrzfe X4J5gDiDhkq/JfvSXIR0fQCBMKIxrpJO4gNJsVI+r0BiMxL5pKK6nXnfSMaa8s0jcdcnKPvd3GWxpkM1i0Kn87D075U5z0w10z4= Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] which error-tag? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:39:30 -0000 Andy Bierman writes: > Which error-tag should be returned if an element is present > but it is disabled because if-feature=false? > I think this is unknown-object, not invalid-value, since the "if-feature" > statements were added to the ietf-netconf.yang module > I don't think the RFC says either way. "unknown-object" makes more sense to me -- the philosophy of the RFC seems to be that the object is nonexistent if if-feature is false. But it should be specified clearly, of course. Dale From nobody Tue Jul 12 08:26:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B506212D88B for ; Tue, 12 Jul 2016 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGeSvd3g9_Pj for ; Tue, 12 Jul 2016 08:26:52 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFE712DE64 for ; Tue, 12 Jul 2016 08:01:25 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id o63so25524401vkg.1 for ; Tue, 12 Jul 2016 08:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mn1+6IiyQQTAUuAOHqdCvHVzyBm1auyuI9pYh/L/r14=; b=UR8dQeAJMNebEk4htSd13Zon6dovZUCSH+9HwIkb7VxSiu3hzRNneryb1ztO+2ED+o nzPKt1BVYD2+Oms+Fd2BFOrpzmba4yeaY5MG8uOBXPfC0aJlzYsQh5nv1/L+ysLtlLjZ 0v+87pJb7UKvnye0NHje5Owomu8qE4Yn4t+v8u0JOlV+UUYtAlQIgfkMwTfabjftMVyJ 1PGDECRXU6ql+lMeZfgy9VU3Ccz2QpdBrhH2L8jNgjFLqgsVVhtJvcfYQ+tT9ceoeUKy j7jYm01cgeIZOQLtie18TUwxaBrNdZAslyOkDsLXezRZIDau5OQvWKe2J968ENE+GfA+ qweQ== 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; bh=Mn1+6IiyQQTAUuAOHqdCvHVzyBm1auyuI9pYh/L/r14=; b=IWXxK82jCIjsiq6CRVk7ic0ynynf56uivc8K2XTHw9/J6eBIubAI4iNZ1qf0hitpEO Ao+0dGi18/fOlzeNM1V1fP8GiO4sThPpl54+SrMdsdBqJWwbMW56v+7g0SUPfWaIBnA/ SGkjpMdjFK/K3UseA434LATZHS6Qw7IJYIfgwsu7KWe/kwFUPnpa42+qZf+jG1A6XqDM bpERppMp6BSdkQzBMH2ZQ5t4BYsUNB/TcYk3czWyuwUqr5lEikMyw2nfOOMj0gwlVBAF n4PoolkqDj9m0XXXc32lh5poa8mzLahECQllPieh2Lnq/HBpEhVSj2PxBx8mvQ9IFsjr jinQ== X-Gm-Message-State: ALyK8tKK0fSfKnc8lwV8kXj7BalyzGCdwegqpGHOGOcZ8Z2buOm2va5uYYD5TAuXaBh7eFUS6dZYHqptekAwvw== X-Received: by 10.31.108.220 with SMTP id j89mr1357965vki.68.1468335684295; Tue, 12 Jul 2016 08:01:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 12 Jul 2016 08:01:23 -0700 (PDT) In-Reply-To: <87oa632cgg.fsf@hobgoblin.ariadne.com> References: <87oa632cgg.fsf@hobgoblin.ariadne.com> From: Andy Bierman Date: Tue, 12 Jul 2016 08:01:23 -0700 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11459bcadfb28f0537718aa0 Archived-At: Cc: Netconf Subject: Re: [Netconf] which error-tag? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:26:54 -0000 --001a11459bcadfb28f0537718aa0 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 12, 2016 at 6:49 AM, Dale R. Worley wrote: > Andy Bierman writes: > > Which error-tag should be returned if an element is present > > but it is disabled because if-feature=false? > > > I think this is unknown-object, not invalid-value, since the "if-feature" > > statements were added to the ietf-netconf.yang module > > I don't think the RFC says either way. > > "unknown-object" makes more sense to me -- the philosophy of the RFC > seems to be that the object is nonexistent if if-feature is false. But > it should be specified clearly, of course. > > It is called unknown-element. The original RFC did not have if-feature statements in the leaf. really-invalid-value Passing a string when the leaf is type 'empty' would be an invalid-value, but only if the leaf is supported. > Dale > Andy --001a11459bcadfb28f0537718aa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 6:49 AM, Dale R. Worley <<= a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
Andy Bierman <andy@yumaworks.com> writes:
> Which error-tag should be returned if an element is present
> but it is disabled because if-feature=3Dfalse?

> I think this is unknown-object, not invalid-value, since the "if-= feature"
> statements were added to the ietf-netconf.yang module
> I don't think the RFC says either way.

"unknown-object" makes more sense to me -- the philosophy of the = RFC
seems to be that the object is nonexistent if if-feature is false.=C2=A0 Bu= t
it should be specified clearly, of course.


It is called unknown-element.
The original= RFC did not have if-feature statements in the <candidate> leaf.

=C2=A0 <lock>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0<target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ru= nning>really-invalid-value</running>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0</target>
=C2=A0 </lock>

Passing a string when the leaf is type 'empty' would be an i= nvalid-value,
but only if the leaf is supported.


=C2=A0
Dale

Andy<= /div>

--001a11459bcadfb28f0537718aa0-- From nobody Tue Jul 12 09:29:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C7512D542 for ; Tue, 12 Jul 2016 09:29:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 BzproImFDEif for ; Tue, 12 Jul 2016 09:29:11 -0700 (PDT) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B73212D53D for ; Tue, 12 Jul 2016 09:29:11 -0700 (PDT) Received: from [192.168.10.101] ([24.13.90.46]) by p3plsmtpa11-07.prod.phx3.secureserver.net with id HsVA1t001100Es801sVAKZ; Tue, 12 Jul 2016 09:29:11 -0700 To: Mahesh Jethanandani , Netconf References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> From: Xiang Li Message-ID: <57851AC9.1090208@seguesoft.com> Date: Tue, 12 Jul 2016 11:28:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> Content-Type: multipart/alternative; boundary="------------050505030502040207090104" Archived-At: Subject: Re: [Netconf] What should a server response be? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 16:29:13 -0000 This is a multi-part message in MIME format. --------------050505030502040207090104 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote: > The Opendaylight controller is constructing this particular set of > requests as part of a single transaction. The response > of the server is to reject the configuration that the particular node > (evpn container) does not exist. > > However, if the default-operation=none is removed or changed to > replace, the server responds with an RPC OK. > > Is the server right in its interpretation of what RFC 6241 says? In > particular, the way the server is interpreting this request is as > follows from Section 7.2 of the RFC: > > none:The target datastore is unaffected by the configuration in the > parameter, unless and until the incoming configuration data > uses the "operation" attribute to request a different operation. If the configuration in the > parameter contains data for which there is not a > corresponding level in the target datastore, an > is returned with an value of data-missing. > Using "none" allows operations like "delete" to avoid > unintentionally creating the parent hierarchy of the element > to be deleted. > > and then this: > > operation: Elements in the subtree MAY contain an > "operation" attribute, which belongs to the NETCONF namespace > defined inSection 3.1 .The attribute identifies the point in the configuration to perform the > operation and MAY appear on multiple elements throughout the > subtree. > > > *_1^st request:_* > > > > > > rollback-on-error > > > > > > > > ## > The container evpn in this case is a non-presence container and does > not contain any mandatory leafs or default statements. The server > therefore interprets that nothing has to be done here, as it is not > required to create a empty container. I think the container node needs to be created when you are merging to create new nodes explicitly. RFC6020 7.5. The container Statement 7.5.8. NETCONF Operations When a NETCONF server processes an request, the elements of procedure for the container node are: If the operation is "merge" or "replace", the node is created if it does not exist. It makes no sense to me for the server to return ok but actually does not create that container node in this case. The server may delete an empty container node but only when you deleting stuff: If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container. > *_2^nd request:_* > > > > > > none > rollback-on-error > > > > a:operation="replace"> > > > > > > > > > ## > > In the second request, the default-operation=none again seems to imply > that nothing needs to be done for creation of the evpn node. Therefore > by the time the evpn-load-balancing request rolls around, the request > is rejected as the parent container does not exist. As stated earlier, > if the default-operation is removed (causing a default of merge) or > replaced with a replace, the transaction succeeds. > > A second interpretation to this transaction is that the server should > have created the evpn node as part of the first request, and that the > none operation was implying that the node had already been created. > If the server returns ok for the first , then it means it has successfully created the top two container nodes in the hierarchy: then the second request should have succeeded. -Xiang Li --------------050505030502040207090104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
The Opendaylight controller is constructing this particular set of <edit-config> requests as part of a single transaction. The response of the server is to reject the configuration that the particular node (evpn container) does not exist. 

However, if the default-operation=none is removed or changed to replace, the server responds with an RPC OK.

Is the server right in its interpretation of what RFC 6241 says? In particular, the way the server is interpreting this request is as follows from Section 7.2 of the RFC:

         none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and then this:

      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


1st request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-23">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <error-option>rollback-on-error</error-option>
    <config>
        <evpn-tables/>
      </evpn>
    </config>
  </edit-config>
</rpc>
##
 
The container evpn in this case is a non-presence container and does not contain any mandatory leafs or default statements. The server therefore interprets that nothing has to be done here, as it is not required to create a empty container.
 


I think the container node needs to be created when you are merging to create new nodes explicitly.
RFC6020
7.5.  The container Statement
   7.5.8.  NETCONF <edit-config> Operations
    When a NETCONF server processes an <edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.
It makes no sense to me for the server to return ok but actually does not create that
container node in this case.


The server may delete an empty container node but only when you deleting stuff:

If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

2nd request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-24">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <error-option>rollback-on-error</error-option>
    <config>
        <evpn-tables>
          <evpn-load-balancing xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
            <enable/>
            <evpn-flow-label/>
          </evpn-load-balancing>
        </evpn-tables>
      </evpn>
    </config>
  </edit-config>
</rpc>
##

In the second request, the default-operation=none again seems to imply that nothing needs to be done for creation of the evpn node. Therefore by the time the evpn-load-balancing request rolls around, the request is rejected as the parent container does not exist. As stated earlier, if the default-operation is removed (causing a default of merge) or replaced with a replace, the transaction succeeds.

A second interpretation to this transaction is that the server should have created the evpn node as part of the first request, and that the none operation was implying that the node had already been created.



If the server returns ok for the first <edit-config>, then it means it has successfully created the top two container nodes in the hierarchy:

      <evpn >
        <evpn-tables>

then the second request should have succeeded.


-Xiang Li
--------------050505030502040207090104-- From nobody Tue Jul 12 10:01:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7323B12D1E6 for ; Tue, 12 Jul 2016 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCAIokkbMjG4 for ; Tue, 12 Jul 2016 10:01:29 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB94D12D17B for ; Tue, 12 Jul 2016 10:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2055; q=dns/txt; s=iport; t=1468342888; x=1469552488; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=dPSR8KQxoN2SGebpphaydEDTfzDpHgnyBOSc5nxNUaQ=; b=T5ezuZynKkIhoXxd1rsMFlEVhi1cRPxq2xAA7EVEAbS0VPxT2Zj7SZDE N2C96Doj1WN2bXDWH3hgHDocOz1XK2HVtcdZ0mwZvK4tHfKWedKNdVfxB wZZIQGnKgNDrrEOJTeJTmVJwdyGJAQ7tnP/2mqbuqX/8z2ngnIVyfLqOS s=; X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="638515834" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2016 17:01:27 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6CH1QHi011395; Tue, 12 Jul 2016 17:01:27 GMT To: NETCONF , Benoit Claise From: Benoit Claise Message-ID: <1bed8194-0656-790d-5f19-5ed7c10669c7@cisco.com> Date: Tue, 12 Jul 2016 19:01:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] In preparation of our NETCONF meeting in Berlin X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 17:01:30 -0000 Dear all, bclaise@bclaise-VirtualBox:~/ietf/YANG-all$ wgstatus -s NETCONF Fetching draft-gonzalez-netconf-5277bis-00 into cache Fetching draft-ietf-netconf-yang-push-00 into cache Fetching draft-ietf-netconf-restconf-00 into cache Fetching draft-ietf-netconf-yang-patch-00 into cache Fetching draft-ietf-netconf-zerotouch-00 into cache # Document Status Since 2016-04-08 00:00:00 ## New RFCs RFC 7895 - YANG Module Library [u'Proposed Standard RFC'] ## New WG-Docs draft-ietf-netconf-restconf-client-server-00 [u'I-D Exists', u'WG Document'] draft-ietf-netconf-system-keychain-00 [u'I-D Exists', u'WG Document'] draft-ietf-netconf-tls-client-server-00 [u'I-D Exists', u'WG Document'] draft-ietf-netconf-netconf-client-server-00 [u'I-D Exists', u'WG Document'] draft-ietf-netconf-ssh-client-server-00 [u'I-D Exists', u'WG Document'] ## Updated WG-Docs draft-ietf-netconf-yang-push-03 [u'I-D Exists', u'WG Document'] draft-ietf-netconf-restconf-15 [u'AD Evaluation::AD Followup', u'for 12 days', u'Submitted to IESG for Publication:', u'Proposed Standard'] draft-ietf-netconf-yang-patch-10 [u'AD Evaluation', u'for 103 days', u'Submitted to IESG for Publication:', u'Proposed Standard'] draft-ietf-netconf-zerotouch-09 [u'I-D Exists', u'WG Document'] ## Existing WG-Docs draft-ietf-netconf-call-home-17 [u'RFC Ed Queue', u': MISSREF', u'for 197 days', u'Submitted to IESG for Publication:', u'Proposed Standard', u'Apr 2015'] draft-ietf-netconf-server-model-09 [u'I-D Exists', u'WG Document'] ## New IDs draft-tp-netconf-datastore-00 [u'I-D Exists'] draft-voit-netconf-restconf-notif-00 [u'I-D Exists'] draft-gonzalez-netconf-event-notifications-00 [u'I-D Exists'] draft-wilton-netconf-opstate-metadata-00 [u'I-D Exists'] ## Updated IDs draft-gonzalez-netconf-5277bis-02 [u'I-D Exists'] ## Existing IDs draft-liu-netconf-multiple-replies-02 [u'I-D Exists'] Agenda: https://datatracker.ietf.org/meeting/96/agenda/netconf/ Regards, Benoit From nobody Tue Jul 12 12:41:24 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7B212D5FF; Tue, 12 Jul 2016 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTac7GKGKTQg; Tue, 12 Jul 2016 12:41:20 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B13512D0EB; Tue, 12 Jul 2016 12:41:17 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id c2so10136362pfa.2; Tue, 12 Jul 2016 12:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gAcOUAIAYCQTgbPZLH9zLFqhmmyxbaMSs5FvLyDl6vc=; b=Vu/huLOngtUOX7ad0mKQHCscCSRQemG+GmPZ0PeanKd7/1pce+dECSgH4bh8HvjFtd hCiIseVDDfJVuUihb2+to/wBjh1biEVDy2EDjgyI1FquzbBlcTCM5Lv/KIcAAOSW/tVn 0yxJKE/dhr7kWL6OWu10xGaJO6spZ2MoILgoss5LH2G9qijXTuGuwPtFOzEqn+X9XQNU kxRtIruIquUoP+24vOMThBHrwli2ZCgPSKCmWJFZjX6uIrwsV0Nf+hdIT3j/WqR5+yLB V5ys/LqxlYS+DiUwznAAH4Uo/bcHERGktS7JoqBSHcl7jLblXpS+SXJ18WkecQzFcNDo Ec1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gAcOUAIAYCQTgbPZLH9zLFqhmmyxbaMSs5FvLyDl6vc=; b=GUN04kTruiivnEaZcYXoM/Ai4HBpUy90MZQxdefVwFbnkHzenE5QlKk1GAyg25TOvT cj/LHikAz224vD2Ye8QAvDoeaLQMgzqDzdckZKTGmnUF8t4vsIwkoXa+jfubeNVembhK 9CEKpCLdx6H2P4/LTmpQi8tby0akycq9D6JR0/4yo8tltI2tZNUf3TkfO3yA6rS5DuMp 5Ov7Ez7DsPQnhTY6aVC7vFqxDF0tDETGma2BnZNOE+oLnkIV8/4jzod622sXD2IBUEKu BWNdAwarGdRiZ/RT6iJOrOiheUyhiX4sLoLuxkM7z2vhy3PPAPTP4gdh3BOzcIobhXqO CUYw== X-Gm-Message-State: ALyK8tI9khpPSS0Tgjer2Xo5zkyco5re4hz+ak+O3lDC700Aut0pWk4Xiw81/4sq0VKSVQ== X-Received: by 10.98.24.194 with SMTP id 185mr35516627pfy.52.1468352476980; Tue, 12 Jul 2016 12:41:16 -0700 (PDT) Received: from dhcp-128-107-151-44.cisco.com (dhcp-128-107-151-44.cisco.com. [128.107.151.44]) by smtp.gmail.com with ESMTPSA id o22sm6092202pfa.15.2016.07.12.12.41.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 12:41:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E61BF51B-2263-46F1-A8C7-EC42B04F6F88" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> Date: Tue, 12 Jul 2016 12:40:56 -0700 Message-Id: <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> To: Jason Sterne , Xiang Li X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 19:41:22 -0000 --Apple-Mail=_E61BF51B-2263-46F1-A8C7-EC42B04F6F88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jason/Xiang, Picking up on this particular point that Benoit brought up in his AD = review. The two of you went back and forth on the thread that he = mentions below and came to a conclusion that one could not replace the = entire configuration using . Martin, added a case ##5 which = went on to demonstrate that only could be use to replace = the entire configuration. Citing specific piece of that e-mail thread: >> ## Initial server Config A (used in all the cases below): >> >> >> 12 >> true >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >=20 >=20 >> ## Case 4: >> - Initial Config A >> - edit-config request (!! with default-operation replace !!): >> >> =20 >> 10 =20 >> =20 >> >> - Resulting config on the server (entire server datastore affected = ?): >> >> >> 10 >> >> >> // no qos data ? >=20 > This is not correct; qos is unaffected. >=20 > ## Case 5: > - Initial Config A > - copy-config request > > =20 > 10 =20 > =20 > > - Resulting config on the server (entire server datastore affected !): > > > 10 > > > // no qos data ! > On Jul 11, 2016, at 9:52 AM, Benoit Claise wrote: >=20 > - modify/replace the entire datastore=20 >=20 > Each YANG patch edit specifies one edit operation on the target = data > node. The set of operations is aligned with the NETCONF edit > operations, but also includes some new operations. >=20 > = +---------------+---------------------------------------------------+ > | Operation | Description = | > = +---------------+---------------------------------------------------+ > | create | create a new data resource if it does not already = | > | | exist or error = | > | delete | delete a data resource if it already exists or = | > | | error = | > | insert | insert a new user-ordered data resource = | > | merge | merge the edit value with the target data = | > | | resource; create if it does not already exist = | > | move | re-order the target data resource = | > | replace | replace the target data resource with the edit = | > | | value = | > | remove | remove a data resource if it already exists or no = | > | | error = | > = +---------------+---------------------------------------------------+ > And, in section 2.1 > This can be the > datastore resource itself, i.e., "{+restconf}/data", or it can be a > configuration data resource within the datastore resource, e.g., > {+restconf/data/ietf-interfaces:interfaces". >=20 > [this relates to this email thread "[Netconf] Is a 'replace' operation = on the candidate datastore always the same as 'remove' + 'merge' ?] > When I look at "replace" above, I'm not sure whether we can = modify/replace the entire datastore. So basically replacing the entire = config from a router.=20 Would you agree with Benoit on the above statement? > I always thought it was only possible with NETCONF, with the support = of the :url capability. With semantics. Right? The question of whether it is = limited to NETCONF did not come up. > So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I = was thinking that "A mechanism to dump and restore configurations is a = primitive operation needed by operators. Standards for pulling and = pushing configurations from/to devices are desirable." could only be = fulfilled with NETCONF. > Now, I'm confused. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E61BF51B-2263-46F1-A8C7-EC42B04F6F88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jason/Xiang,

Picking up on this particular point that Benoit brought up in = his AD review. The two of you went back and forth on the thread that he = mentions below and came to a conclusion that one could not replace the = entire configuration using <edit-config>. Martin, added a case ##5 = which went on to demonstrate that only <copy-config> could be use = to replace the entire configuration. Citing specific piece of that = e-mail thread:

## Initial server Config = A (used in all the cases below):
 <system>
   <password-control>
     <min-length>12</min-leng= th>
     <require-caps>true<requi= re-caps>
   </password-control>
   <console>
     <width>132</width>     <enabled>true</enabled&g= t;
   </console>
 </system>
 <qos>
   <ingress>
     <class-limit>8</class-li= mit>
     <sub-classes>true</sub-c= lasses>
   </ingress>
 </qos>

## = Case 4:
- Initial Config A
- edit-config = request (!! with default-operation replace !!):
    <system>
      <password-control> =                     <min-length&= gt;10</min-length>  
      </password-control> =  
    </system>
- Resulting config on the server (entire server datastore = affected ?):
    <system>
      <password-control>        <min-length&= gt;10</min-length>
      </password-control>    </system>
   // no qos data ?

This is not = correct; qos is unaffected.

## Case 5:
- Initial Config A
- copy-config request
   <system>
      <password-control> =                     <min-length&= gt;10</min-length>  
     </password-control> =  
    </system>
- Resulting config on the server (entire server datastore = affected !):
    <system>
      <password-control>       <min-length>10&= lt;/min-length>
     </password-control>
    </system>
   // no qos data !

On Jul 11, 2016, at 9:52 AM, Benoit Claise <bclaise@cisco.com> = wrote:

- modify/replace the = entire datastore 

   Each YANG patch =
edit specifies one edit operation on the target data
   node.  The set of operations is aligned with the NETCONF edit
   operations, but also includes some new operations.

   +---------------+---------------------------------------------------+
   | Operation     | Description                                       |
   +---------------+---------------------------------------------------+
   | create        | create a new data resource if it does not already |
   |               | exist or error                                    |
   | delete        | delete a data resource if it already exists or    |
   |               | error                                             |
   | insert        | insert a new user-ordered data resource           |
   | merge         | merge the edit value with the target data         |
   |               | resource; create if it does not already exist     |
   | move          | re-order the target data resource                 |
   | replace       | replace the target data resource with the edit    |
   |               | value                                             |
   | remove        | remove a data resource if it already exists or no |
   |               | error                                             |
   =
+---------------+---------------------------------------------------+And, in =
section 2.1
 =
  This can be the
   datastore resource itself, i.e., "{+restconf}/data", or it can be a
   configuration data resource within the datastore resource, e.g.,
   {+restconf/data/ietf-interfaces:interfaces".

[this relates to this email thread "[Netconf] Is =
a 'replace' operation on the candidate datastore always the same as =
'remove' + 'merge' ?]
When I look at "replace" above, I'm not sure whether we can =
modify/replace the entire datastore. So basically replacing the entire =
config from a router. 

Would you agree with Benoit on the above = statement?

I always thought it was only possible with NETCONF, with the = support of the :url capability.

With= <copy-config> semantics. Right? The question of whether it is = limited to NETCONF did not come up.

So when comparing = the RFC 3535 requirements again NETCONF/RESCONF, I was thinking that "A = mechanism to dump and restore configurations is a primitive operation = needed by operators. Standards for pulling and pushing configurations = from/to devices are desirable." could only be fulfilled with NETCONF.
Now, I'm confused.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_E61BF51B-2263-46F1-A8C7-EC42B04F6F88-- From nobody Tue Jul 12 13:16:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAEE12B041; Tue, 12 Jul 2016 13:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vNRZO_Vy8aoJ; Tue, 12 Jul 2016 13:16:51 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB5F12D639; Tue, 12 Jul 2016 13:16:50 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 4F8A1B9DE98B2; Tue, 12 Jul 2016 20:16:47 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6CKGnIe023168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2016 20:16:49 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6CKGn1R032540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Jul 2016 20:16:49 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 12 Jul 2016 16:16:49 -0400 From: "Sterne, Jason (Nokia - CA)" To: Mahesh Jethanandani , Xiang Li Thread-Topic: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 Thread-Index: AQHR3HVel1Uy+6S5I0qYKqK3OOcrQKAVOpMQ Date: Tue, 12 Jul 2016 20:16:48 +0000 Message-ID: References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> In-Reply-To: <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC78C8US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 20:16:53 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CCC78C8US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mahesh, I'm not positive what you are asking. I agree that we concluded that NETCONF can *not* be used to r= eplace or delete an entire datastore. That is only supported in NETCONF us= ing specific "root level" RPCs (i.e. and ). I'm not familiar enough with RESTCONF or patch to comment on whether those = allow a mix of replacing subtrees and/or entire datastores with the same pr= imitive/RPC. Note that replacing an entire datastore implies that you dele= te every node of every single data model in the router. In other words -> = if a device supported a mix of proprietary + IETF + OpenConfig models then = a "replace at root" (i.e. equivalent of ) would have to replac= e all data in all those namespaces. Jason From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] Sent: Tuesday, July 12, 2016 15:41 To: Sterne, Jason (Nokia - CA); Xiang Li Cc: draft-ietf-netconf-yang-patch@ietf.org; NETCONF; Benoit Claise Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 Jason/Xiang, Picking up on this particular point that Benoit brought up in his AD review= . The two of you went back and forth on the thread that he mentions below a= nd came to a conclusion that one could not replace the entire configuration= using . Martin, added a case ##5 which went on to demonstrate= that only could be use to replace the entire configuration. = Citing specific piece of that e-mail thread: ## Initial server Config A (used in all the cases below): 12 true 132 true 8 true ## Case 4: - Initial Config A - edit-config request (!! with default-operation replace !!): 10 - Resulting config on the server (entire server datastore affected ?): 10 // no qos data ? This is not correct; qos is unaffected. ## Case 5: - Initial Config A - copy-config request 10 - Resulting config on the server (entire server datastore affected !): 10 // no qos data ! On Jul 11, 2016, at 9:52 AM, Benoit Claise > wrote: - modify/replace the entire datastore Each YANG patch edit specifies one edit operation on the target data node. The set of operations is aligned with the NETCONF edit operations, but also includes some new operations. +---------------+---------------------------------------------------+ | Operation | Description | +---------------+---------------------------------------------------+ | create | create a new data resource if it does not already | | | exist or error | | delete | delete a data resource if it already exists or | | | error | | insert | insert a new user-ordered data resource | | merge | merge the edit value with the target data | | | resource; create if it does not already exist | | move | re-order the target data resource | | replace | replace the target data resource with the edit | | | value | | remove | remove a data resource if it already exists or no | | | error | +---------------+---------------------------------------------------+ And, in section 2.1 This can be the datastore resource itself, i.e., "{+restconf}/data", or it can be a configuration data resource within the datastore resource, e.g., {+restconf/data/ietf-interfaces:interfaces". [this relates to this email thread "[Netconf] Is a 'replace' operation on t= he candidate datastore always the same as 'remove' + 'merge' ?] When I look at "replace" above, I'm not sure whether we can modify/replace = the entire datastore. So basically replacing the entire config from a route= r. Would you agree with Benoit on the above statement? I always thought it was only possible with NETCONF, with the support of the= :url capability. With semantics. Right? The question of whether it is limited = to NETCONF did not come up. So when comparing the RFC 3535 requirements again NETCONF/RESCONF, I was th= inking that "A mechanism to dump and restore configurations is a primitive = operation needed by operators. Standards for pulling and pushing configurat= ions from/to devices are desirable." could only be fulfilled with NETCONF. Now, I'm confused. Mahesh Jethanandani mjethanandani@gmail.com --_000_A125E53CE190A749957C19483DC79F9F5CCC78C8US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

 <= /p>

I’m not positive wh= at you are asking. 

 <= /p>

I agree that we concluded= that NETCONF <edit-config> can *not* be used to replace or de= lete an entire datastore.  That is only supported in NETCONF using specific “root level” RPCs (i.e. <copy-config> and <d= elete-config>).

 <= /p>

I’m not familiar en= ough with RESTCONF or patch to comment on whether those allow a mix of repl= acing subtrees and/or entire datastores with the same primitive/RPC.  Note that replacing an entire datastore implies that you delete every node= of every single data model in the router.  In other words -> if a = device supported a mix of proprietary + IETF + OpenConfig models th= en a “replace at root” (i.e. equivalent of <copy-config>) would have to replace all data in all those namespaces.<= /p>

 <= /p>

Jason

 <= /p>

From: Mahesh J= ethanandani [mailto:mjethanandani@gmail.com]
Sent: Tuesday, July 12, 2016 15:41
To: Sterne, Jason (Nokia - CA); Xiang Li
Cc: draft-ietf-netconf-yang-patch@ietf.org; NETCONF; Benoit Claise Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

 

Jason/Xiang,

 

Picking up on this particular point that Benoit brou= ght up in his AD review. The two of you went back and forth on the thread t= hat he mentions below and came to a conclusion that one could not replace t= he entire configuration using <edit-config>. Martin, added a case ##5 which went on to demonstrate that only <copy-c= onfig> could be use to replace the entire configuration. Citing specific= piece of that e-mail thread:

 

## Initial server Config A (used in all the cases be= low):
 <system>
   <password-control>
     <min-length>12</min-length>
     <require-caps>true<require-caps><= br>    </password-control>
   <console>
     <width>132</width>
     <enabled>true</enabled>
   </console>
 </system>
 <qos>
   <ingress>
     <class-limit>8</class-limit>
     <sub-classes>true</sub-classes>    </ingress>
 </qos>

 

## Case 4:
- Initial Config A
- edit-config request (!! with default-operation replace !!):
    <system>
      <password-control>   &n= bsp;         
        <min-length>10</mi= n-length>  
      </password-control>  
    </system>
- Resulting config on the server (entire server datastore affected ?):
    <system>
      <password-control>
        <min-length>10</mi= n-length>
      </password-control>
    </system>
   // no qos data ?

 

This is not correct; qos is unaffected.

## Case 5:
- Initial Config A
- copy-config request
   <system>
      <password-control>   &n= bsp;         
        <min-length>10</mi= n-length>  
     </password-control>  
    </system>
- Resulting config on the server (entire server datastore affected !):
    <system>
      <password-control>
       <min-length>10</min-leng= th>
     </password-control>
    </system>
   // no qos data !

 

On Jul 11, 2016, at 9:52 AM, Benoit Claise <bclaise@cisco.com> wrote:=

 

- modify/replace the entire datastore 

   Each YANG patch edit specifies one edit operati=
on on the target data
   node.  The set of op=
erations is aligned with the NETCONF edit
   operations, but also incl=
udes some new operations.
 
   +---------------+=
---------------------------------------------------+<=
/pre>

   | Operation  &n=
bsp;  | Description        &nb=
sp;            =
            &nb=
sp;     |


   +---------------+=
---------------------------------------------------+<=
/pre>

   | create   =
;     | create a new data resource if it does not alrea=
dy |


   |    =
           | exist or err=
or            &=
nbsp;           &nbs=
p;           |=



   | delete   =
;     | delete a data resource if it already exists or&=
nbsp;   |


   |    =
           | error &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |


   | insert   =
;     | insert a new user-ordered data resource &n=
bsp;         |

   | merge   =
      | merge the edit value with the target data&=
nbsp;        |


   |    =
           | resource; cr=
eate if it does not already exist     |


   | move   &=
nbsp;      | re-order the target data resource&nbs=
p;            &=
nbsp;   |


   | replace  &nbs=
p;    | replace the target data resource with the edit =
   |


   |    =
           | value &=
nbsp;            &nb=
sp;            =
            &nb=
sp;     |


   | remove   =
;     | remove a data resource if it already exists or =
no |


   |    =
           | error &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |


   +---------------+=
---------------------------------------------------+<=
/pre>

And, in section 2.1






   This can be the


   datastore resource itself=
, i.e., "{+restconf}/data", or it can be a<=
/pre>

   configuration data resour=
ce within the datastore resource, e.g.,


   {+restconf/data/ietf-=
interfaces:interfaces".




[this relates to this email thread "[=
Netconf] Is a 'replace' operation on the candidate datastore always the sam=
e as 'remove' + 'merge' ?]

When I look at "replace" above, =
I'm not sure whether we can modify/replace the entire datastore. So basical=
ly replacing the entire config from a router. 

 

Would you agree with Benoit on the above statement?<= o:p>



I always thought it was = only possible with NETCONF, with the support of the :url capability.

 

With <copy-config> semantics. Right? The quest= ion of whether it is limited to NETCONF did not come up.



So when comparing the RF= C 3535 requirements again NETCONF/RESCONF, I was thinking that "A mech= anism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from= /to devices are desirable." could only be fulfilled with NETCONF.
Now, I'm confused.

 

Mahesh Jethanandani

 

 

 

--_000_A125E53CE190A749957C19483DC79F9F5CCC78C8US70TWXCHMBA11z_-- From nobody Tue Jul 12 13:44:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A75712D731; Tue, 12 Jul 2016 13:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg4G-9_kPnR7; Tue, 12 Jul 2016 13:44:41 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096FD12D63C; Tue, 12 Jul 2016 13:44:41 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id pp5so3270350pac.3; Tue, 12 Jul 2016 13:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=6R94J5ak1V6PDcP0USbdVFHI43Ygu5QC22ufOci+0C8=; b=Ew0Rp+j7rAWVVDN/dy/p98V8XBnGymNP/f2Fb7ZIPFPyYlkWy041JGf5tSNmNGOPoV jXwtSdeOV9N/QMr15C7neuwS9aECSVRKOizwb4w3JFhlPHsnjFfTMXxn3waGQ+NHRrAG xsMtkanp4uRwcBN7qprV2Y3qeqeMifGT8oqpiQSlDll+DiZZ8gRYhN5h85qoJNNo0bL1 d0Yr2Tm9LDdrdr6zU4b58Xj7mUqzPF63JRiu70CKQ3GhNo49gtpKCyvJrOX9UHILa2DV CyODS0JRPzvOALmI2YvwQqaFnOplzemup1hDXKcwcKCSAdMSMVIJtQFkKXYj6DQ9ewfY OekA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6R94J5ak1V6PDcP0USbdVFHI43Ygu5QC22ufOci+0C8=; b=gJryTp4ZSgjJj+p7nQ3PkbMtCqnDkeKkuPE+quUG+5s2DX2pErl9rqi/u7JyjZb5Vi qHYVOcWH3xjrgPB1DDlJoMT99ZO4GAcZ/PZGCooshsjtih5CYQwjADFKNu7xrWiddg+s KCac+y2MddMNXlG40Tf6CqOmuVp65qzEjZvVPrCp45vE/IIIljGuXoJBlYu09yHf56a6 eEY8zuVAwA8EOr7zY8Olj2fsvMYk6jxlCraexmctD4oE/mG6oQWVcd5gKxCLXCbOzq6i Awlmuh+uid0pQv4Pav2wTUN/lmXbEeNeAJUZEh/gy/bmgFsWiTWpGdu2z1RatWdTNgWh 2rkw== X-Gm-Message-State: ALyK8tJpwANC0sgfsEcZ94gEjvyMRQtfq3QvbwdNShuPV00lkJf03365aIhkmN55oq+fVQ== X-Received: by 10.66.236.133 with SMTP id uu5mr7407666pac.35.1468356280446; Tue, 12 Jul 2016 13:44:40 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:3854:d262:d582:680d? ([2001:420:30d:1320:3854:d262:d582:680d]) by smtp.gmail.com with ESMTPSA id cl15sm7086635pac.15.2016.07.12.13.44.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 13:44:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D82143E-1F71-4CAD-A341-4F444AF01B15" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Tue, 12 Jul 2016 13:44:37 -0700 Message-Id: References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> To: NETCONF , "draft-ietf-netconf-yang-patch@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 20:44:42 -0000 --Apple-Mail=_3D82143E-1F71-4CAD-A341-4F444AF01B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok. We seem to agree that cannot be used to replace or = delete an entire configuration.=20 Though the discussion was in the context of NETCONF, I would venture to = say the same would apply to RESTCONF and YANG Patch also. So the following statement: >=20 > And, in section 2.1 >=20 > This can be the > datastore resource itself, i.e., "{+restconf}/data", or it can be a > configuration data resource within the datastore resource, e.g., > {+restconf/data/ietf-interfaces:interfaces". >=20 where we are referencing the entire datastore =E2=80=9C{+restconf}/data=E2= =80=9D seems to imply that the entire data store can be replaced or = deleted using edit operations is not correct. Does anyone disagree? Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3D82143E-1F71-4CAD-A341-4F444AF01B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok. We seem to agree that <edit-config> cannot be used = to replace or delete an entire configuration. 

Though the discussion was in the = context of NETCONF, I would venture to say the same would apply to = RESTCONF and YANG Patch also.

So the following statement:


And, in section = 2.1

   This =
can be the
   datastore resource itself, i.e., =
"{+restconf}/data", or it can be a
   configuration data =
resource within the datastore resource, e.g.,
   =
{+restconf/data/ietf-interfaces:interfaces".


where we are referencing the entire = datastore =E2=80=9C{+restconf}/data=E2=80=9D seems to imply that the = entire data store can be replaced or deleted using edit operations is = not correct.

Does anyone disagree?

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_3D82143E-1F71-4CAD-A341-4F444AF01B15-- From nobody Tue Jul 12 14:08:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A100512D8C4 for ; Tue, 12 Jul 2016 14:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG1uyk2C14Mm for ; Tue, 12 Jul 2016 14:08:06 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFFB12D8B7 for ; Tue, 12 Jul 2016 14:08:06 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id v6so39859780vkb.2 for ; Tue, 12 Jul 2016 14:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9bvvhC/krLJ76gEs0+oGVjQEmLZIr1qUu+dvy8DcyN4=; b=sXujBnSiN5i6pKPOEEWMV/WAzxFZoNXzK0ns90xq6O8odHo19s7DCYgwuSl/JP/C2P euxH1wkRnO3Xif8sN+Y0nAbeojhcxqyyCGCvc+KojkWHwSat5TOyZQf56494iMKrzJ+l KI/RHvAHU78jAhcA9scRcJaCeIMmQw4HGB4xfq/HCUzmnN4XgEbCOpc81uRIilUapsng SmbMM4Eu8LBXccOAaRA8V2bCZxAI5Q2xRdvrfVfc8JA2ioRsUBQ9d45SMduOSy7lNmj6 LsbLl4yGprNa8BnELHRedfL5Jm5ZxRR45DcKTuQKQjPoLGClb/xL0pVkz4ONMtqkXZjr h8pA== 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; bh=9bvvhC/krLJ76gEs0+oGVjQEmLZIr1qUu+dvy8DcyN4=; b=g8N5Z5g1kaLOF00skfrk9AJbq+aZtunu72gOmkstgZiOHv//RDn1hav6J9q9VKha4f 301jZlYck0l/aH+nfydqPZtS9TUUH5yTBNg73H0d795EvX4P5oC0HDam0aiOhktRycLf BPK79lukFqS3ghmmTj+3nTOLJEkUDDw9+W5CamQiOv2sJcnIoJvQAYBRwumPklPUA8ZT tbZnAuXPWWPpT9mrMn1tggzN/M9+LSfIOXKT19WsdMuVHQ822rCzXFoc8RYn86XnrzLO r0+rkBSLIdHy+QtWjStcgu5jNuDNVRWWSEz/8MKNVTeaZHIm6w5xp1OSC4hMOKk7Jsgr n56w== X-Gm-Message-State: ALyK8tJXQkduS/C1b8+pLY5DDR+l7mVOS8ipYBMD2OaZn8dveB0OdBUONm2/mfgjNB/9xbBQq6DN3H15KKezeQ== X-Received: by 10.159.40.74 with SMTP id c68mr2246852uac.9.1468357685402; Tue, 12 Jul 2016 14:08:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 12 Jul 2016 14:08:04 -0700 (PDT) In-Reply-To: References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> From: Andy Bierman Date: Tue, 12 Jul 2016 14:08:04 -0700 Message-ID: To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=94eb2c04486a3e02c7053776aac9 Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 21:08:08 -0000 --94eb2c04486a3e02c7053776aac9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, YANG Patch does not replace the entire datastore. If the target resource is the datastore then each edit target is relative to the datastore root. Andy On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Ok. We seem to agree that cannot be used to replace or > delete an entire configuration. > > Though the discussion was in the context of NETCONF, I would venture to > say the same would apply to RESTCONF and YANG Patch also. > > So the following statement: > > > And, in section 2.1 > > This can be the > > datastore resource itself, i.e., "{+restconf}/data", or it can be a > > configuration data resource within the datastore resource, e.g., > > {+restconf/data/ietf-interfaces:interfaces". > > > > where we are referencing the entire datastore =E2=80=9C{+restconf}/data= =E2=80=9D seems to > imply that the entire data store can be replaced or deleted using edit > operations is not correct. > > Does anyone disagree? > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > --94eb2c04486a3e02c7053776aac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

YANG Patch does not replace the ent= ire datastore.
If the target resource is the datastore then each = edit target
is relative to the datastore root.


Andy


On Tue, Jul 12, 2016 at 1:44 PM, Mahesh= Jethanandani <mjethanandani@gmail.com> wrote:
Ok. We seem = to agree that <edit-config> cannot be used to replace or delete an en= tire configuration.=C2=A0

Though the discussion was in t= he context of NETCONF, I would venture to say the same would apply to RESTC= ONF and YANG Patch also.

So the following statement:


And, in section 2.1

=C2=A0=C2=A0 This can be the<=
/u>
=C2=A0=C2=A0 datastore resourc=
e itself, i.e., "{+restconf}/data", or it can be a<=
/span>
=C2=A0=C2=A0 configuration data resource =
within the datastore resource, e.g.,
=C2=A0=C2=A0 {+restconf/data/ietf-interfaces:interfaces".<=
u>


where= we are referencing the entire datastore =E2=80=9C{+restconf}/data=E2=80=9D= seems to imply that the entire data store can be replaced or deleted using= edit operations is not correct.

Does anyone disag= ree?

Mahesh Jethanandani




--94eb2c04486a3e02c7053776aac9-- From nobody Tue Jul 12 18:45:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4DD12B035 for ; Tue, 12 Jul 2016 18:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waKk9zx4fEii for ; Tue, 12 Jul 2016 18:45:41 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D2112B004 for ; Tue, 12 Jul 2016 18:45:41 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id pp5so5507129pac.3 for ; Tue, 12 Jul 2016 18:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=YiXXPnHqWF1K/pFFz9pNuGALyqZn/1fQmvvz/N6Yh8w=; b=lAVcgwdbqgVm7oYetrEiBkl3nCHBFrvj5Ytm8493AULYqp/ZY72YTrkQgbXjrNFF6y 3duSKhaTYwR7zycXGuEXJ3oXhCgGy4WN5SdC5q7R//7zoMFE3DeDK/3FjPbxGXCXgV/9 P05Yv1FcC5o0zex74MMgGFRuj37RfaSlFeTo0wtAqkawRVGcQ3ib3TEzx+zjy7pHJtnN ODR9ubKePWBkAjzq9B61pAFEjhxalZ8hNpGlonAy/Lvx5fu219Xo+3QXsB9LzARQKTys 4D17ie6izl8uVX9DvuBO6oJL4p79j5iKarjJxOFO1gMxgHGW/97NlTz9MTeijTFA/ns3 oBPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YiXXPnHqWF1K/pFFz9pNuGALyqZn/1fQmvvz/N6Yh8w=; b=H8LDcWNToE+WvQsiIdfyfOE3S87UO5fvU4FtfA4kx1zt7V2rLeKslPGQVL7oZH/K1w C5mZTuXEp/RrsCrnMmLlAs6Is3n/KDtBrSELwt6qYhGAD20P99bafzy375wAOtlxf9Qu oOydnqQPpYDuiWg4ZHzLUDVa7khWCgOxJ9IYtIFRpsUkvo7tKry2vFsJrSX65kDbZAC6 5aMA7/ayn/G+9xc2a8b2veAjf+YPB0F9PWO7zJlUN3lty8ClFS25sJDb7z2pvurXEdDL 6sN63bZpg3Wa/BwLEX3+TbkD0DAU6ZUK+Uj0q+vqdfAu5NJIrCLP6Nr6NXy+cT8YcsTM 3RJw== X-Gm-Message-State: ALyK8tIt4EuccIQThglK6eD5bhRxw+LfFOWKpJFtWnN+jGExdu8MdaR7RJVPhiAH9NmTKA== X-Received: by 10.66.167.103 with SMTP id zn7mr9050091pab.149.1468374340669; Tue, 12 Jul 2016 18:45:40 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:c1d0:f4eb:66f0:bae2? ([2001:420:30d:1320:c1d0:f4eb:66f0:bae2]) by smtp.gmail.com with ESMTPSA id g80sm5684512pfk.51.2016.07.12.18.45.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 18:45:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A0634027-18A2-4ACD-820B-1A0B9B483065" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <57851AC9.1090208@seguesoft.com> Date: Tue, 12 Jul 2016 18:45:36 -0700 Message-Id: <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> To: Xiang Li X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 01:45:43 -0000 --Apple-Mail=_A0634027-18A2-4ACD-820B-1A0B9B483065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 12, 2016, at 9:28 AM, Xiang Li wrote: >=20 > On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote: >> The Opendaylight controller is constructing this particular set of = requests as part of a single transaction. The response of = the server is to reject the configuration that the particular node (evpn = container) does not exist.=20 >>=20 >> However, if the default-operation=3Dnone is removed or changed to = replace, the server responds with an RPC OK. >>=20 >> Is the server right in its interpretation of what RFC 6241 says? In = particular, the way the server is interpreting this request is as = follows from Section 7.2 of the RFC: >>=20 >> none: The target datastore is unaffected by the = configuration >> in the parameter, unless and until the incoming >> configuration data uses the "operation" attribute to = request >> a different operation. If the configuration in the = >> parameter contains data for which there is not a >> corresponding level in the target datastore, an = >> is returned with an value of data-missing. >> Using "none" allows operations like "delete" to avoid >> unintentionally creating the parent hierarchy of the = element >> to be deleted. >>=20 >> and then this: >>=20 >> operation: Elements in the subtree MAY contain an >> "operation" attribute, which belongs to the NETCONF = namespace >> defined in Section 3.1 = . The attribute = identifies the point in >> the configuration to perform the operation and MAY appear on >> multiple elements throughout the subtree. >>=20 >>=20 >> 1st request: >> =20 >> >> >> >> >> >> rollback-on-error >> >> http://cisco.com/ns/yang/= Cisco-IOS-XR-l2vpn-cfg = "> >> >> >> >> >> >> ## >> =20 >> The container evpn in this case is a non-presence container and does = not contain any mandatory leafs or default statements. The server = therefore interprets that nothing has to be done here, as it is not = required to create a empty container. >> =20 >=20 >=20 > I think the container node needs to be created when you are merging to = create new nodes explicitly. > RFC6020=20 > 7.5. The container Statement > 7.5.8. NETCONF Operations > When a NETCONF server processes an request, the > elements of procedure for the container node are: >=20 > If the operation is "merge" or "replace", the node is created if > it does not exist. >=20 > It makes no sense to me for the server to return ok but actually does = not create that > container node in this case. And that is the clarification I am seeking. Note, it is an empty = non-presence container. Should the server create this empty container, = and if so how would it be represented in the config tree? In this = particular case, the request is followed by child nodes. What happens if = no child nodes are created? >=20 >=20 > The server may delete an empty container node but only when you = deleting stuff: >=20 > If a container does not have a "presence" statement and the last > child node is deleted, the NETCONF server MAY delete the container. For a delete it is clear. But the RFC is silent for a create (and the = default operation of merge). If a non-presence empty container can be = deleted, why should it be created? Thanks. >=20 >=20 >=20 >=20 >> 2nd request: >> =20 >> >> >> >> >> >> none >> rollback-on-error >> >> http://cisco.com/ns/yang/= Cisco-IOS-XR-l2vpn-cfg = "> >> >> >> >> >> >> >> >> >> >> >> ## >>=20 >> In the second request, the default-operation=3Dnone again seems to = imply that nothing needs to be done for creation of the evpn node. = Therefore by the time the evpn-load-balancing request rolls around, the = request is rejected as the parent container does not exist. As stated = earlier, if the default-operation is removed (causing a default of = merge) or replaced with a replace, the transaction succeeds. >>=20 >> A second interpretation to this transaction is that the server should = have created the evpn node as part of the first request, and that the = none operation was implying that the node had already been created. >>=20 >=20 >=20 > If the server returns ok for the first , then it means it = has successfully created the top two container nodes in the hierarchy: >=20 > > >=20 > then the second request should have succeeded. >=20 >=20 > -Xiang Li Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A0634027-18A2-4ACD-820B-1A0B9B483065 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On Jul 12, 2016, at 9:28 AM, Xiang Li <xiangli@seguesoft.com> wrote:

On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
The Opendaylight controller is constructing this particular set of <edit-config> requests as part of a single transaction. The response of the server is to reject the configuration that the particular node (evpn container) does not exist. 

However, if the default-operation=none is removed or changed to replace, the server responds with an RPC OK.

Is the server right in its interpretation of what RFC 6241 says? In particular, the way the server is interpreting this request is as follows from Section 7.2 of the RFC:

         none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and then this:

      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


1st request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-23">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <error-option>rollback-on-error</error-option>
    <config>
        <evpn-tables/>
      </evpn>
    </config>
  </edit-config>
</rpc>
##
 
The container evpn in this case is a non-presence container and does not contain any mandatory leafs or default statements. The server therefore interprets that nothing has to be done here, as it is not required to create a empty container.
 


I think the container node needs to be created when you are merging to create new nodes explicitly.
RFC6020
7.5.  The container Statement
   7.5.8.  NETCONF <edit-config> Operations
    When a NETCONF server processes an <edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.
It makes no sense to me for the server to return ok but actually does not create that
container node in this case.

And that is the clarification I am seeking. Note, it is an empty non-presence container. Should the server create this empty container, and if so how would it be represented in the config tree? In this particular case, the request is followed by child nodes. What happens if no child nodes are created?



The server may delete an empty container node but only when you deleting stuff:

If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

For a delete it is clear. But the RFC is silent for a create (and the default operation of merge). If a non-presence empty container can be deleted, why should it be created?

Thanks.

2nd request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-24">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <error-option>rollback-on-error</error-option>
    <config>
        <evpn-tables>
          <evpn-load-balancing xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
            <enable/>
            <evpn-flow-label/>
          </evpn-load-balancing>
        </evpn-tables>
      </evpn>
    </config>
  </edit-config>
</rpc>
##

In the second request, the default-operation=none again seems to imply that nothing needs to be done for creation of the evpn node. Therefore by the time the evpn-load-balancing request rolls around, the request is rejected as the parent container does not exist. As stated earlier, if the default-operation is removed (causing a default of merge) or replaced with a replace, the transaction succeeds.

A second interpretation to this transaction is that the server should have created the evpn node as part of the first request, and that the none operation was implying that the node had already been created.



If the server returns ok for the first <edit-config>, then it means it has successfully created the top two container nodes in the hierarchy:

      <evpn >
        <evpn-tables>

then the second request should have succeeded.


-Xiang Li

Mahesh Jethanandani



--Apple-Mail=_A0634027-18A2-4ACD-820B-1A0B9B483065-- From nobody Tue Jul 12 20:37:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95612DA4A; Tue, 12 Jul 2016 20:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4SLa1lEKfYa; Tue, 12 Jul 2016 20:37:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE23F12D67D; Tue, 12 Jul 2016 20:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12558; q=dns/txt; s=iport; t=1468381062; x=1469590662; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KvDHPK+gi38G86w3LMHMIqYvHi3j3ra/F427Ewf/bbg=; b=Qg1Nc15CkW8HtVGkKtcQ0JMa7cXXhDPyTAt9ygUrVg8KmGY7nIzCXk8M roDGxJUS3rii7K3ZudCQAJmqFAY7ZJgcY0k6YLtdTAuQSwxeDEvevenSE ScK+1P426KiBTszcpO3wqGMiGq0KUJ1Iw5F/wqhsMUdKxszFHMkSbbKQa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAgAAt4VX/5xdJa1bgnBOVnwGrHKHE?= =?us-ascii?q?4UEgXmGGAIcgR44FAEBAQEBAQFlJ4RcAQEFIwpMEAIBCBEEAQEoAwICAh8RFAk?= =?us-ascii?q?IAgQBDQUIiA4DF7EbilkNhB4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYJDg?= =?us-ascii?q?jSCS4JaBZhoNAGMQIIPjzaIH4d3AR42g3FuiCZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,355,1464652800"; d="scan'208,217";a="125289626" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2016 03:37:42 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6D3bgaP015064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 03:37:42 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 22:37:41 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 22:37:41 -0500 From: "Steve Truong (struong)" To: Andy Bierman , Mahesh Jethanandani Thread-Topic: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 Thread-Index: AQHR25SkquoBF6glOUaxzPSetF/ye6AVh0UAgAAKBgCAAAfFgIAABo4AgAAMlsA= Date: Wed, 13 Jul 2016 03:37:41 +0000 Message-ID: <036c8810ea1b48b8b38a69f25fb16b1a@XCH-RCD-014.cisco.com> References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.27.196] Content-Type: multipart/alternative; boundary="_000_036c8810ea1b48b8b38a69f25fb16b1aXCHRCD014ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 03:37:44 -0000 --_000_036c8810ea1b48b8b38a69f25fb16b1aXCHRCD014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBndWVzcyB3ZSBoYXZlIHRvIHZpZXcgdGhlIGRvY3VtZW50IHVuZGVyIHRoZSBjb25jZXB0IG9m IHBhdGNoaW5nIGFuZCBwYXRjaGluZyBpcyBuZXZlciByZXBsYWNpbmcuDQpCdXQgSSB0aGluayB0 aGVyZSBpcyBhIG5lZWQgdG8gcmVwbGFjZSB0aGUgZGF0YXN0b3JlIHVzaW5nIHJlc3Rjb25mLCBv ciBub3Q/DQoNCnN0ZXZlDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFR1ZXNkYXksIEp1bHkg MTIsIDIwMTYgMjowOCBQTQ0KVG86IE1haGVzaCBKZXRoYW5hbmRhbmkNCkNjOiBkcmFmdC1pZXRm LW5ldGNvbmYteWFuZy1wYXRjaEBpZXRmLm9yZzsgTkVUQ09ORg0KU3ViamVjdDogUmU6IFtOZXRj b25mXSBBRCByZXZpZXc6IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXBhdGNoLTEwDQoNCkhpLA0K DQpZQU5HIFBhdGNoIGRvZXMgbm90IHJlcGxhY2UgdGhlIGVudGlyZSBkYXRhc3RvcmUuDQpJZiB0 aGUgdGFyZ2V0IHJlc291cmNlIGlzIHRoZSBkYXRhc3RvcmUgdGhlbiBlYWNoIGVkaXQgdGFyZ2V0 DQppcyByZWxhdGl2ZSB0byB0aGUgZGF0YXN0b3JlIHJvb3QuDQoNCg0KQW5keQ0KDQoNCk9uIFR1 ZSwgSnVsIDEyLCAyMDE2IGF0IDE6NDQgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5h bmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0K T2suIFdlIHNlZW0gdG8gYWdyZWUgdGhhdCA8ZWRpdC1jb25maWc+IGNhbm5vdCBiZSB1c2VkIHRv IHJlcGxhY2Ugb3IgZGVsZXRlIGFuIGVudGlyZSBjb25maWd1cmF0aW9uLg0KDQpUaG91Z2ggdGhl IGRpc2N1c3Npb24gd2FzIGluIHRoZSBjb250ZXh0IG9mIE5FVENPTkYsIEkgd291bGQgdmVudHVy ZSB0byBzYXkgdGhlIHNhbWUgd291bGQgYXBwbHkgdG8gUkVTVENPTkYgYW5kIFlBTkcgUGF0Y2gg YWxzby4NCg0KU28gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQoNCg0KQW5kLCBpbiBzZWN0aW9u IDIuMQ0KDQogICBUaGlzIGNhbiBiZSB0aGUNCg0KICAgZGF0YXN0b3JlIHJlc291cmNlIGl0c2Vs ZiwgaS5lLiwgInsrcmVzdGNvbmZ9L2RhdGEiLCBvciBpdCBjYW4gYmUgYQ0KDQogICBjb25maWd1 cmF0aW9uIGRhdGEgcmVzb3VyY2Ugd2l0aGluIHRoZSBkYXRhc3RvcmUgcmVzb3VyY2UsIGUuZy4s DQoNCiAgIHsrcmVzdGNvbmYvZGF0YS9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcyIuDQoNCg0K d2hlcmUgd2UgYXJlIHJlZmVyZW5jaW5nIHRoZSBlbnRpcmUgZGF0YXN0b3JlIOKAnHsrcmVzdGNv bmZ9L2RhdGHigJ0gc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUgZW50aXJlIGRhdGEgc3RvcmUgY2Fu IGJlIHJlcGxhY2VkIG9yIGRlbGV0ZWQgdXNpbmcgZWRpdCBvcGVyYXRpb25zIGlzIG5vdCBjb3Jy ZWN0Lg0KDQpEb2VzIGFueW9uZSBkaXNhZ3JlZT8NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpl dGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoN Cg0KDQo= --_000_036c8810ea1b48b8b38a69f25fb16b1aXCHRCD014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBndWVzcyB3ZSBoYXZlIHRvIHZpZXcgdGhlIGRvY3VtZW50IHVuZGVyIHRoZSBjb25jZXB0IG9m IHBhdGNoaW5nIGFuZCBwYXRjaGluZyBpcyBuZXZlciByZXBsYWNpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIHRoaW5rIHRoZXJlIGlzIGEgbmVlZCB0byByZXBsYWNlIHRo ZSBkYXRhc3RvcmUgdXNpbmcgcmVzdGNvbmYsIG9yIG5vdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnN0ZXZlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBOZXRjb25mIFttYWlsdG86bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxMiwgMjAxNiAyOjA4IFBNPGJyPg0KPGI+ VG86PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLW5l dGNvbmYteWFuZy1wYXRjaEBpZXRmLm9yZzsgTkVUQ09ORjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW05ldGNvbmZdIEFEIHJldmlldzogZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gtMTA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllBTkcgUGF0Y2ggZG9lcyBub3QgcmVwbGFj ZSB0aGUgZW50aXJlIGRhdGFzdG9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSB0YXJnZXQgcmVzb3VyY2UgaXMgdGhlIGRhdGFzdG9y ZSB0aGVuIGVhY2ggZWRpdCB0YXJnZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmlzIHJlbGF0aXZlIHRvIHRoZSBkYXRhc3RvcmUgcm9vdC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBKdWwgMTIsIDIwMTYgYXQgMTo0NCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pay4gV2Ugc2VlbSB0byBhZ3JlZSB0aGF0ICZsdDtl ZGl0LWNvbmZpZyZndDsgY2Fubm90IGJlIHVzZWQgdG8gcmVwbGFjZSBvciBkZWxldGUgYW4gZW50 aXJlIGNvbmZpZ3VyYXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaG91Z2ggdGhlIGRpc2N1c3Npb24gd2FzIGluIHRoZSBjb250ZXh0IG9m IE5FVENPTkYsIEkgd291bGQgdmVudHVyZSB0byBzYXkgdGhlIHNhbWUgd291bGQgYXBwbHkgdG8g UkVTVENPTkYgYW5kIFlBTkcgUGF0Y2ggYWxzby48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50OjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6d2hpdGUi PkFuZCwgaW4gc2VjdGlvbiAyLjE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmUg c3R5bGU9InRleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7IFRoaXMgY2FuIGJlIHRoZTwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsgZGF0YXN0b3JlIHJl c291cmNlIGl0c2VsZiwgaS5lLiwgJnF1b3Q7eyYjNDM7cmVzdGNvbmZ9L2RhdGEmcXVvdDssIG9y IGl0IGNhbiBiZSBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFs aWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQi PiZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9uIGRhdGEgcmVzb3VyY2Ugd2l0aGluIHRoZSBkYXRh c3RvcmUgcmVzb3VyY2UsIGUuZy4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJ0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQiPiZuYnNwOyZuYnNwOyB7JiM0MztyZXN0Y29uZi9kYXRhL2lldGYtaW50ZXJmYWNl czppbnRlcmZhY2VzJnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGVyZSB3ZSBhcmUgcmVmZXJlbmNpbmcgdGhl IGVudGlyZSBkYXRhc3RvcmUg4oCceyYjNDM7cmVzdGNvbmZ9L2RhdGHigJ0gc2VlbXMgdG8gaW1w bHkgdGhhdCB0aGUgZW50aXJlIGRhdGEgc3RvcmUgY2FuIGJlIHJlcGxhY2VkIG9yIGRlbGV0ZWQg dXNpbmcgZWRpdCBvcGVyYXRpb25zIGlzIG5vdCBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIGFueW9uZSBkaXNhZ3JlZT88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhy ZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1qZXRo YW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_036c8810ea1b48b8b38a69f25fb16b1aXCHRCD014ciscocom_-- From nobody Tue Jul 12 20:43:20 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05712D9C1 for ; Tue, 12 Jul 2016 20:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xls0o4pI8HWD for ; Tue, 12 Jul 2016 20:43:15 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4FD12D67D for ; Tue, 12 Jul 2016 20:43:14 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id o63so48508055vkg.1 for ; Tue, 12 Jul 2016 20:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6J4qyjf9fYHI9gZsyQVhcmIVmoXL6SqV4HIOS2uAQBE=; b=jj5hOnWoprkOu8FhZda+q66Dv3XHp+WZbGVgTvZhL2Gob8Mot8Nag6Ck/lxosOgaT0 LBI0yZB2kJRzioDPrDWadlQAReLNcf5Dc0jT0k23k3NMqztMLPOHP/sPzl5DWdrZtM1x JWJ7KPfAH42b1cENSY4KW8qu+iN44OmnH4uaLVR5pf0vzUk1x0zczWBYtZlY6in/Sk4p k22sVf7Q/e4QDkRZheH6/2ML+fnwCDMTGla3yFd5FljqP84bJiEvT5kCKRPrmx527ZDz +kd5RmD+XeszFhVEJndt7S8gkasxg8k1Zbpte8YLU2JZh8Lk1NUw6u5bG46QU66xu0sj I8Aw== 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; bh=6J4qyjf9fYHI9gZsyQVhcmIVmoXL6SqV4HIOS2uAQBE=; b=EsMWo1+1a68AXJDPmAs95dFz9Dy015vyPaGreq0mqHtTCSrx/AJBkBWc5obLxP92vV QMs86RPg1P3WaylOvdOPPvNaCokLCYk7REcAexEYqQt5iSRsusoDn3D91p8dRv/udFg6 00lDmD+7BzYbSmF0ib/lm/M3aTg2EkOTjGIdp6cRCaZYFl1gmxd6NuIP6b4WyL12joqO bnJ2xpb7oDtbMbt5jOyIPmmc8PC0zEwvDSpKZ+Xl5NviwJpSangtGci6Nw8KAM6/vQ3N v6lOS5Kz4e4NgIIR6/yL9Hn0AKiIGgDCMlWn4BLsrmGeETlNtFsHeSoQXvOhouTmmZKz oTyg== X-Gm-Message-State: ALyK8tJmhVDP6H/FJa18U2MnDT24OGXAJ0RGE7HgZgPdCdiez5yu4DRxDJqNNUXVBbOEIwmXOZzrV+eOwcsmbA== X-Received: by 10.31.4.4 with SMTP id 4mr2953664vke.121.1468381393970; Tue, 12 Jul 2016 20:43:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Tue, 12 Jul 2016 20:43:13 -0700 (PDT) In-Reply-To: <036c8810ea1b48b8b38a69f25fb16b1a@XCH-RCD-014.cisco.com> References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> <036c8810ea1b48b8b38a69f25fb16b1a@XCH-RCD-014.cisco.com> From: Andy Bierman Date: Tue, 12 Jul 2016 20:43:13 -0700 Message-ID: To: "Steve Truong (struong)" Content-Type: multipart/alternative; boundary=001a114298c861fa7905377c2f39 Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 03:43:18 -0000 --001a114298c861fa7905377c2f39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2016 at 8:37 PM, Steve Truong (struong) wrote: > I guess we have to view the document under the concept of patching and > patching is never replacing. > > But I think there is a need to replace the datastore using restconf, or > not? > > > Try: PUT /restconf/data { "data" : { ... entire config } } > steve > > > Andy > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Tuesday, July 12, 2016 2:08 PM > *To:* Mahesh Jethanandani > *Cc:* draft-ietf-netconf-yang-patch@ietf.org; NETCONF > *Subject:* Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 > > > > Hi, > > > > YANG Patch does not replace the entire datastore. > > If the target resource is the datastore then each edit target > > is relative to the datastore root. > > > > > > Andy > > > > > > On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Ok. We seem to agree that cannot be used to replace or > delete an entire configuration. > > > > Though the discussion was in the context of NETCONF, I would venture to > say the same would apply to RESTCONF and YANG Patch also. > > > > So the following statement: > > > > > > And, in section 2.1 > > This can be the > > datastore resource itself, i.e., "{+restconf}/data", or it can be a > > configuration data resource within the datastore resource, e.g., > > {+restconf/data/ietf-interfaces:interfaces". > > > > > > where we are referencing the entire datastore =E2=80=9C{+restconf}/data= =E2=80=9D seems to > imply that the entire data store can be replaced or deleted using edit > operations is not correct. > > > > Does anyone disagree? > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > --001a114298c861fa7905377c2f39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 8:37 PM, Steve Truong (struong) <struong@cisco= .com> wrote:

I guess we have to view t= he document under the concept of patching and patching is never replacing.<= u>

But I think there is a ne= ed to replace the datastore using restconf, or not?

=C2=A0

<= /div>


Try:
<= br>
=C2=A0 =C2=A0PUT /restconf/data

=C2= =A0 =C2=A0{ "data" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0... e= ntire config
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

=C2=A0

steve

=C2=A0

<= /div>

Andy
=C2=A0

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, July 12, 2016 2:08 PM
To: Mahesh Jethanandani
Cc: draft-ietf-netconf-yang-patch@ietf.org; NETCONF
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

=C2=A0

Hi,

=C2=A0

YANG Patch does not replace the entire datastore.=

If the target resource is the datastore then each ed= it target

is relative to the datastore root.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani= <mjethanan= dani@gmail.com> wrote:

Ok. We seem to agree that <edit-config> cannot= be used to replace or delete an entire configuration.=C2=A0<= /p>

=C2=A0

Though the discussion was in the context of NETCONF,= I would venture to say the same would apply to RESTCONF and YANG Patch als= o.

=C2=A0

So the following statement:

=C2=A0

=C2=A0

And, in section 2.1

=C2=A0=C2=A0 This can be the
=C2=A0=C2=A0 datastore resource itself, i.e., "{+restconf}/data&=
quot;, or it can be a
=C2=A0=C2=A0 configuration data resource within the datastore resourc=
e, e.g.,
=C2=A0=C2=A0 {+restconf/data/ietf-interfaces:interfaces".=

=C2=A0

=C2=A0

where we are referencing the entire datastore =E2=80= =9C{+restconf}/data=E2=80=9D seems to imply that the entire data store can = be replaced or deleted using edit operations is not correct.<= /p>

=C2=A0

Does anyone disagree?

=C2=A0

Mahesh Jethanandani=

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a114298c861fa7905377c2f39-- From nobody Tue Jul 12 20:46:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD52412D097; Tue, 12 Jul 2016 20:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbZpU9AXdoVR; Tue, 12 Jul 2016 20:46:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C133312B02B; Tue, 12 Jul 2016 20:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21238; q=dns/txt; s=iport; t=1468381575; x=1469591175; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tE6PmvS1fC591mkeHg0Nfb31BKGRzMN7tiYe5sFcQPI=; b=GU3iSbT1h3PVkqXnqoi5BYD1nsSDxHgQG1n25wXVBENbjzu0GZv0qpmy pZbB+npqwGsGfks2KZFg0ILExfALv0ZT49FSndJIzt9iqCZJoMuwtmcre BhOVsQP7FHVyn1rM9qNL8wDszOQ1GSBLAiL4wxELy9lhy+xSt/XCeddZ6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAgCfuIVX/4YNJK1bgnBOVnwGrHKMF?= =?us-ascii?q?4F5hhgCHIEeOBQBAQEBAQEBZSeEXAEBBSMKTBACAQgRBAEBKAMCAgIfERQJCAI?= =?us-ascii?q?EDgUIiA4DF7EbiloNhB4BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYJDgjSCS?= =?us-ascii?q?4JaBZhoNAGMQIIPjzaIH4d3AR42g3FuiCZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,355,1464652800"; d="scan'208,217";a="297047837" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2016 03:46:14 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6D3kEn6024106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 03:46:14 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 22:46:14 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 22:46:14 -0500 From: "Steve Truong (struong)" To: Andy Bierman Thread-Topic: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 Thread-Index: AQHR25SkquoBF6glOUaxzPSetF/ye6AVh0UAgAAKBgCAAAfFgIAABo4AgAAMlsCAAGHRgP//rGxQ Date: Wed, 13 Jul 2016 03:46:14 +0000 Message-ID: <3947cf6bd7dc4971953f42d7c9e4f407@XCH-RCD-014.cisco.com> References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> <036c8810ea1b48b8b38a69f25fb16b1a@XCH-RCD-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.27.196] Content-Type: multipart/alternative; boundary="_000_3947cf6bd7dc4971953f42d7c9e4f407XCHRCD014ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 03:46:17 -0000 --_000_3947cf6bd7dc4971953f42d7c9e4f407XCHRCD014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFuZHkgZm9yIGNvbmZpcm1pbmcgdGhhdCBmb3IgZGF0YXN0b3JlIHJlcGxhY2luZyB3 ZSBjYW4gdXNlIHRoZSDigJxiYXNl4oCdIHJlc3Rjb25mIGZhY2lsaXR5Lg0KDQpzdGV2ZQ0KDQpG cm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUdWVz ZGF5LCBKdWx5IDEyLCAyMDE2IDg6NDMgUE0NClRvOiBTdGV2ZSBUcnVvbmcgKHN0cnVvbmcpDQpD YzogTWFoZXNoIEpldGhhbmFuZGFuaTsgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2hAaWV0 Zi5vcmc7IE5FVENPTkYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gQUQgcmV2aWV3OiBkcmFmdC1p ZXRmLW5ldGNvbmYteWFuZy1wYXRjaC0xMA0KDQoNCg0KT24gVHVlLCBKdWwgMTIsIDIwMTYgYXQg ODozNyBQTSwgU3RldmUgVHJ1b25nIChzdHJ1b25nKSA8c3RydW9uZ0BjaXNjby5jb208bWFpbHRv OnN0cnVvbmdAY2lzY28uY29tPj4gd3JvdGU6DQpJIGd1ZXNzIHdlIGhhdmUgdG8gdmlldyB0aGUg ZG9jdW1lbnQgdW5kZXIgdGhlIGNvbmNlcHQgb2YgcGF0Y2hpbmcgYW5kIHBhdGNoaW5nIGlzIG5l dmVyIHJlcGxhY2luZy4NCkJ1dCBJIHRoaW5rIHRoZXJlIGlzIGEgbmVlZCB0byByZXBsYWNlIHRo ZSBkYXRhc3RvcmUgdXNpbmcgcmVzdGNvbmYsIG9yIG5vdD8NCg0KDQoNClRyeToNCg0KICAgUFVU IC9yZXN0Y29uZi9kYXRhDQoNCiAgIHsgImRhdGEiIDogew0KICAgICAgIC4uLiBlbnRpcmUgY29u ZmlnDQogICAgICB9DQogICAgfQ0KDQoNCnN0ZXZlDQoNCg0KQW5keQ0KDQpGcm9tOiBOZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDEyLCAyMDE2IDI6MDggUE0NClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpDYzogZHJhZnQtaWV0 Zi1uZXRjb25mLXlhbmctcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0Y29uZi15 YW5nLXBhdGNoQGlldGYub3JnPjsgTkVUQ09ORg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBBRCBy ZXZpZXc6IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXBhdGNoLTEwDQoNCkhpLA0KDQpZQU5HIFBh dGNoIGRvZXMgbm90IHJlcGxhY2UgdGhlIGVudGlyZSBkYXRhc3RvcmUuDQpJZiB0aGUgdGFyZ2V0 IHJlc291cmNlIGlzIHRoZSBkYXRhc3RvcmUgdGhlbiBlYWNoIGVkaXQgdGFyZ2V0DQppcyByZWxh dGl2ZSB0byB0aGUgZGF0YXN0b3JlIHJvb3QuDQoNCg0KQW5keQ0KDQoNCk9uIFR1ZSwgSnVsIDEy LCAyMDE2IGF0IDE6NDQgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KT2suIFdlIHNl ZW0gdG8gYWdyZWUgdGhhdCA8ZWRpdC1jb25maWc+IGNhbm5vdCBiZSB1c2VkIHRvIHJlcGxhY2Ug b3IgZGVsZXRlIGFuIGVudGlyZSBjb25maWd1cmF0aW9uLg0KDQpUaG91Z2ggdGhlIGRpc2N1c3Np b24gd2FzIGluIHRoZSBjb250ZXh0IG9mIE5FVENPTkYsIEkgd291bGQgdmVudHVyZSB0byBzYXkg dGhlIHNhbWUgd291bGQgYXBwbHkgdG8gUkVTVENPTkYgYW5kIFlBTkcgUGF0Y2ggYWxzby4NCg0K U28gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQoNCg0KQW5kLCBpbiBzZWN0aW9uIDIuMQ0KDQog ICBUaGlzIGNhbiBiZSB0aGUNCg0KICAgZGF0YXN0b3JlIHJlc291cmNlIGl0c2VsZiwgaS5lLiwg InsrcmVzdGNvbmZ9L2RhdGEiLCBvciBpdCBjYW4gYmUgYQ0KDQogICBjb25maWd1cmF0aW9uIGRh dGEgcmVzb3VyY2Ugd2l0aGluIHRoZSBkYXRhc3RvcmUgcmVzb3VyY2UsIGUuZy4sDQoNCiAgIHsr cmVzdGNvbmYvZGF0YS9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcyIuDQoNCg0Kd2hlcmUgd2Ug YXJlIHJlZmVyZW5jaW5nIHRoZSBlbnRpcmUgZGF0YXN0b3JlIOKAnHsrcmVzdGNvbmZ9L2RhdGHi gJ0gc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUgZW50aXJlIGRhdGEgc3RvcmUgY2FuIGJlIHJlcGxh Y2VkIG9yIGRlbGV0ZWQgdXNpbmcgZWRpdCBvcGVyYXRpb25zIGlzIG5vdCBjb3JyZWN0Lg0KDQpE b2VzIGFueW9uZSBkaXNhZ3JlZT8NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFu aUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KDQoNCg== --_000_3947cf6bd7dc4971953f42d7c9e4f407XCHRCD014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBBbmR5IGZvciBjb25m aXJtaW5nIHRoYXQgZm9yIGRhdGFzdG9yZSByZXBsYWNpbmcgd2UgY2FuIHVzZSB0aGUg4oCcYmFz ZeKAnSByZXN0Y29uZiBmYWNpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnN0ZXZlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxMiwgMjAxNiA4OjQz IFBNPGJyPg0KPGI+VG86PC9iPiBTdGV2ZSBUcnVvbmcgKHN0cnVvbmcpPGJyPg0KPGI+Q2M6PC9i PiBNYWhlc2ggSmV0aGFuYW5kYW5pOyBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaEBpZXRm Lm9yZzsgTkVUQ09ORjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIEFEIHJldmll dzogZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gtMTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEp1bCAxMiwgMjAxNiBhdCA4OjM3IFBNLCBTdGV2ZSBUcnVvbmcgKHN0cnVv bmcpICZsdDs8YSBocmVmPSJtYWlsdG86c3RydW9uZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5r Ij5zdHJ1b25nQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIGd1ZXNzIHdlIGhhdmUgdG8gdmlldyB0aGUgZG9jdW1lbnQgdW5k ZXIgdGhlIGNvbmNlcHQgb2YgcGF0Y2hpbmcgYW5kIHBhdGNoaW5nIGlzIG5ldmVyIHJlcGxhY2lu Zy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSB0aGluayB0aGVyZSBpcyBh IG5lZWQgdG8gcmVwbGFjZSB0aGUgZGF0YXN0b3JlIHVzaW5nIHJlc3Rjb25mLCBvciBub3Q/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHJ5Ojxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7UFVUIC9yZXN0Y29uZi9kYXRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt7ICZxdW90O2RhdGEmcXVvdDsg OiB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi4gZW50aXJlIGNvbmZpZzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5zdGV2ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTmV0Y29uZiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSnVseSAxMiwgMjAxNiAyOjA4IFBNPGJyPg0KPGI+VG86PC9iPiBN YWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1uZXRjb25mLXlhbmctcGF0Y2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0 LWlldGYtbmV0Y29uZi15YW5nLXBhdGNoQGlldGYub3JnPC9hPjsgTkVUQ09ORjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIEFEIHJldmlldzogZHJhZnQtaWV0Zi1uZXRjb25mLXlh bmctcGF0Y2gtMTA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGks PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WUFORyBQ YXRjaCBkb2VzIG5vdCByZXBsYWNlIHRoZSBlbnRpcmUgZGF0YXN0b3JlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB0aGUgdGFyZ2V0IHJl c291cmNlIGlzIHRoZSBkYXRhc3RvcmUgdGhlbiBlYWNoIGVkaXQgdGFyZ2V0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmlzIHJlbGF0aXZlIHRv IHRoZSBkYXRhc3RvcmUgcm9vdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBKdWwgMTIsIDIwMTYg YXQgMTo0NCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9rLiBXZSBzZWVtIHRvIGFncmVlIHRoYXQgJmx0O2VkaXQtY29uZmlnJmd0OyBjYW5u b3QgYmUgdXNlZCB0byByZXBsYWNlIG9yIGRlbGV0ZSBhbiBlbnRpcmUgY29uZmlndXJhdGlvbi4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aG91Z2ggdGhlIGRpc2N1c3Npb24gd2FzIGluIHRoZSBjb250ZXh0IG9mIE5FVENPTkYsIEkgd291 bGQgdmVudHVyZSB0byBzYXkgdGhlIHNhbWUgd291bGQgYXBwbHkgdG8gUkVTVENPTkYgYW5kIFlB TkcgUGF0Y2ggYWxzby48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TbyB0aGUgZm9sbG93aW5nIHN0YXRlbWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 YmFja2dyb3VuZDp3aGl0ZSI+QW5kLCBpbiBzZWN0aW9uIDIuMTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsgVGhpcyBjYW4gYmUg dGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOnN0YXJ0 O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPiZuYnNwOyZu YnNwOyBkYXRhc3RvcmUgcmVzb3VyY2UgaXRzZWxmLCBpLmUuLCAmcXVvdDt7JiM0MztyZXN0Y29u Zn0vZGF0YSZxdW90Oywgb3IgaXQgY2FuIGJlIGE8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9InRleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gZGF0YSByZXNvdXJj ZSB3aXRoaW4gdGhlIGRhdGFzdG9yZSByZXNvdXJjZSwgZS5nLiw8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7IHsmIzQzO3Jlc3Rjb25mL2Rh dGEvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPndoZXJl IHdlIGFyZSByZWZlcmVuY2luZyB0aGUgZW50aXJlIGRhdGFzdG9yZSDigJx7JiM0MztyZXN0Y29u Zn0vZGF0YeKAnSBzZWVtcyB0byBpbXBseSB0aGF0IHRoZSBlbnRpcmUgZGF0YSBzdG9yZSBjYW4g YmUgcmVwbGFjZWQgb3IgZGVsZXRlZCB1c2luZyBlZGl0IG9wZXJhdGlvbnMgaXMgbm90IGNvcnJl Y3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Eb2VzIGFueW9uZSBkaXNhZ3JlZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+TWFoZXNoIEpldGhhbmFuZGFuaTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5p QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3947cf6bd7dc4971953f42d7c9e4f407XCHRCD014ciscocom_-- From nobody Wed Jul 13 06:15:55 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D939712D13F; Wed, 13 Jul 2016 06:15:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.27.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160713131553.16137.37890.idtracker@ietfa.amsl.com> Date: Wed, 13 Jul 2016 06:15:53 -0700 Archived-At: Cc: draft-ietf-netconf-restconf@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org Subject: [Netconf] Last Call: (RESTCONF Protocol) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 13:15:54 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'RESTCONF Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jul 13 10:15:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95D12D1A3 for ; Wed, 13 Jul 2016 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg8IAsjsU5UF for ; Wed, 13 Jul 2016 10:15:26 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9068612D13D for ; Wed, 13 Jul 2016 10:15:26 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id j126so20535547vkg.3 for ; Wed, 13 Jul 2016 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tDtzlrOZXfPxmdCyFrH7nEzuU64pRVeu1GOs5o5eI10=; b=OFRe7LHmQC+CLCL78qjxr6E1JGzVn8W+3oceehD5rroDfdPhhH1u+zWYZto2iffCvR Ku5NiZ77zPEe4Az1npcpFhqOic4J4biA/xqHmB8xrhYUD1lMzTbNhTZiqwp7nJbchA5U aERxBvx7s8oobCSlU1OUZdlABHoHyPv9P3tuax4XFjigjpoc2UNdClfJLZcBhBaXbAMW N9bZnp34k2NHFTwihKKjVIo1VyPRRR3wL2M0tpJdjG6q/A8PzfIXihoeFHVWHqTSCcks ej75NWVj/9BKYhIVT3reu9KmoqXE1k4Yi+flZ57fB5l5ARupiBvJJG2VcdrxmSj91b8Z qh8g== 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; bh=tDtzlrOZXfPxmdCyFrH7nEzuU64pRVeu1GOs5o5eI10=; b=ZAkF1ZOVqakNFjSgzFQCVluKXU5H/2Il7fC6/NUhEYlZwmE4/RPrMEg7wcTnQu/GJA orTHBdNNJHYNQ+U42/t1FV9BbD92/6XCSwnwBseokFNrBFfHlg79GvwnySXSzO5rwfhX mImDak33XC1Z1BxjgH8iT2Czen5h7RGjIZkdTpXoWNz4FM1Ld7aJH9W/m6NWsekI1y4p pNarKfKzba1fusWmJOEzl8tMVGRisEv6+b2lB95ddjd8qEIgUFnBsezZb4f/cXK73QRX /XENMShsCzX8yotbh0/pDYjJZthtR+LsPTW/NEcKWPJGx4Fi/y8cH6BBTCl7P3IEeUe0 Doew== X-Gm-Message-State: ALyK8tLgomAHzXRH3KLGog943aMkDICpYNVFMyJjm7FdemfOo/xx7YAPzBLB39HRCHVJa8Cqgn30tvwMLl/yKQ== X-Received: by 10.159.35.112 with SMTP id 103mr4455015uae.55.1468430125677; Wed, 13 Jul 2016 10:15:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 13 Jul 2016 10:15:24 -0700 (PDT) In-Reply-To: <3947cf6bd7dc4971953f42d7c9e4f407@XCH-RCD-014.cisco.com> References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com> <036c8810ea1b48b8b38a69f25fb16b1a@XCH-RCD-014.cisco.com> <3947cf6bd7dc4971953f42d7c9e4f407@XCH-RCD-014.cisco.com> From: Andy Bierman Date: Wed, 13 Jul 2016 10:15:24 -0700 Message-ID: To: "Steve Truong (struong)" Content-Type: multipart/alternative; boundary=001a113ab81a04d7160537878888 Archived-At: Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 17:15:28 -0000 --001a113ab81a04d7160537878888 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2016 at 8:46 PM, Steve Truong (struong) wrote: > Thanks Andy for confirming that for datastore replacing we can use the > =E2=80=9Cbase=E2=80=9D restconf facility. > > > Not so fast... restconf-15, sec 4.5 The only target resource media type that supports PUT is the data resource. The message-body is expected to contain the content used to create or replace the target resource. I know our server code does not accept a replace-datastore via PUT right now, but it could. I support adding text that allows PUT to be used on a datastore resource as well. > steve > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Tuesday, July 12, 2016 8:43 PM > *To:* Steve Truong (struong) > *Cc:* Mahesh Jethanandani; draft-ietf-netconf-yang-patch@ietf.org; NETCON= F > *Subject:* Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 > > > > > > > > On Tue, Jul 12, 2016 at 8:37 PM, Steve Truong (struong) > wrote: > > I guess we have to view the document under the concept of patching and > patching is never replacing. > > But I think there is a need to replace the datastore using restconf, or > not? > > > > > > > > Try: > > > > PUT /restconf/data > > > > { "data" : { > > ... entire config > > } > > } > > > > > > steve > > > > > > Andy > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Tuesday, July 12, 2016 2:08 PM > *To:* Mahesh Jethanandani > *Cc:* draft-ietf-netconf-yang-patch@ietf.org; NETCONF > *Subject:* Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10 > > > > Hi, > > > > YANG Patch does not replace the entire datastore. > > If the target resource is the datastore then each edit target > > is relative to the datastore root. > > > > > > Andy > > > > > > On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Ok. We seem to agree that cannot be used to replace or > delete an entire configuration. > > > > Though the discussion was in the context of NETCONF, I would venture to > say the same would apply to RESTCONF and YANG Patch also. > > > > So the following statement: > > > > > > And, in section 2.1 > > This can be the > > datastore resource itself, i.e., "{+restconf}/data", or it can be a > > configuration data resource within the datastore resource, e.g., > > {+restconf/data/ietf-interfaces:interfaces". > > > > > > where we are referencing the entire datastore =E2=80=9C{+restconf}/data= =E2=80=9D seems to > imply that the entire data store can be replaced or deleted using edit > operations is not correct. > > > > Does anyone disagree? > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > --001a113ab81a04d7160537878888 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 8:46 PM, Steve Truong (struong) <struong@cisco= .com> wrote:

Thanks Andy for confirming that for datastor= e replacing we can use the =E2=80=9Cbase=E2=80=9D restconf facility.=

=C2=A0



Not so fast...

= 

restconf-15, sec 4.5


   The only target resource media type that supports PUT is the data
   resource.  The message-body is expected to contain the content used=C2=
=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0to create or replace the target resource.
<= div>

I know our server code does not accept a = replace-datastore via PUT right now, but it could.

I support adding text that allows PUT to be used on a datastore resource a= s well.


=C2=A0

steve


Andy
=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Tuesday, July 12, 2016 8:43 PM
To: Steve Truong (struong)
Cc: Mahesh Jethanandani; draft-ietf-netconf-yang-patch@ietf.org= ; NETCONF
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

=C2=A0

=C2=A0

=C2=A0

On Tue, Jul 12, 2016 at 8:37 PM, Steve Truong (struo= ng) <struong@cisc= o.com> wrote:

I guess we have to view the document under t= he concept of patching and patching is never replacing.

But I think there is a need to replace the d= atastore using restconf, or not?

=C2=A0

=C2=A0

=C2=A0

Try:

=C2=A0

=C2=A0 =C2=A0PUT /restconf/data

=C2=A0

=C2=A0 =C2=A0{ "data" : {

=C2=A0 =C2=A0 =C2=A0 =C2=A0... entire config<= u>

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 }

=C2=A0

=C2=A0

steve

=C2=A0

=C2=A0

Andy

=C2=A0

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, July 12, 2016 2:08 PM
To: Mahesh Jethanandani
Cc: draft-ietf-netconf-yang-patch@ietf.org; NETCONF
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10

=C2=A0

Hi,

=C2=A0

YANG Patch does not replace the entire datastore.=

If the target resource is the datastore then each ed= it target

is relative to the datastore root.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani= <mjethanan= dani@gmail.com> wrote:

Ok. We seem to agree that <edit-config> cannot= be used to replace or delete an entire configuration.=C2=A0<= /p>

=C2=A0

Though the discussion was in the context of NETCONF,= I would venture to say the same would apply to RESTCONF and YANG Patch als= o.

=C2=A0

So the following statement:

=C2=A0

=C2=A0

And, in section 2.= 1

=C2=A0=C2=A0 This can be the
=C2=A0=C2=A0 datastore resource itself, i.e., "{+restconf}/data&qu=
ot;, or it can be a
=C2=A0=C2=A0 configuration data resource within the datastore resource,=
 e.g.,
=C2=A0=C2=A0 {+restconf/data/ietf-interfaces:interfaces".

=C2=A0

=C2=A0

where we are referencing the entire datastore =E2=80= =9C{+restconf}/data=E2=80=9D seems to imply that the entire data store can = be replaced or deleted using edit operations is not correct.<= /p>

=C2=A0

Does anyone disagree?

=C2=A0=

Mahesh Jethan= andani

=C2=A0=

=C2=A0=

=C2=A0=

=C2=A0

=C2=A0


--001a113ab81a04d7160537878888-- From nobody Wed Jul 13 11:54:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D0C12B035 for ; Wed, 13 Jul 2016 11:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUZ8bN7i5a2g for ; Wed, 13 Jul 2016 11:54:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6958912B00D for ; Wed, 13 Jul 2016 11:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6749; q=dns/txt; s=iport; t=1468436070; x=1469645670; h=from:to:subject:date:message-id:mime-version; bh=2t/5IoPBFQUOxFBteO38Rb/AudxF7oa539Y3ITQwCI0=; b=dkqdii8Vgpbfo2aAwXVmvLp7GEozT43xu15nldJ8HBySimUUAlbBsKoW HiJt9/8nu8/QhYO+CZrjYJvoBWXe1S4PoDsMyxIq5sLKAlQA2nIqqtfJ7 8PFQSvUYwRTiyA8sYgqf7v+jTf940VKV7b4cQJRUwE1QiTS+MegCoN3OG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgDZjYZX/4UNJK1bgnBOVoECs16FB?= =?us-ascii?q?IF7JIcoOBQBAQEBAQEBZRwLhGMdEDsjAS1TJgEEG4goDqIunlUBAQEBAQEEAQE?= =?us-ascii?q?BAQEBHAWGKo5pBZNehT4BgTOEXYg/jzaQFgEeNoNxiSZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,358,1464652800"; d="scan'208,217";a="123789795" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jul 2016 18:54:29 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6DIsTn3029929 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jul 2016 18:54:29 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 13 Jul 2016 14:54:28 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 13 Jul 2016 14:54:28 -0400 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: Subscribing to Network Elements @ IETF96 - Thursday 10AM Thread-Index: AdHdN/cd07bshjPUTCyz8ZfQi3+MlA== Date: Wed, 13 Jul 2016 18:54:28 +0000 Message-ID: <09d23b6a25784819b933f433b733c47d@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.232] Content-Type: multipart/alternative; boundary="_000_09d23b6a25784819b933f433b733c47dXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Subscribing to Network Elements @ IETF96 - Thursday 10AM X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 18:54:33 -0000 --_000_09d23b6a25784819b933f433b733c47dXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A NETCONF agenda item for Wednesday will be the set of Subscription drafts.= A call for adoption will be requested by the authors on three of these d= rafts. One has already been adopted. Because these drafts are coupled, we= are having an Intro session for those of you who haven't followed this dai= ly and would like to learn more. IETF-96 Thursday 10:00-11:30AM Tegel Conference Room Material covered: Requirements for Subscription to YANG Datastores RFC 7923 Subscriptions for Event Notifications (RFC5277bis) draft-gonzalez-netconf-5277bis YANG Datastore Push draft-ietf-netconf-yang-push NETCONF Transport for Event Notifications draft-gonzalez-netconf-event-notifications RESTCONF & HTTP Transport for Event Notifications draft-voit-netconf-restconf-notif Thanks! Eric (on behalf of the authors and contributors) --_000_09d23b6a25784819b933f433b733c47dXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A NETCONF agenda item for Wednesday will be the set = of Subscription drafts.   A call for adoption will be requested b= y the authors on three of these drafts.  One has already been adopted.=   Because these drafts are coupled, we are having an Intro session for those of you who haven’t followed this daily an= d would like to learn more. 

 

        &nbs= p;      IETF-96

Thursday  10:00-11:3= 0AM

        &nbs= p;      Tegel Conference Room

 

Material covered:

 

        &nbs= p;      Requirements for Subscription to YANG Data= stores

RFC 7923 

 

Subscriptions for Event N= otifications  (RFC5277bis)

draft-gonzalez-netconf-5277bis

 

YANG Datastore Push

draft-ietf-netconf-yan= g-push

 

NETCONF Transport for Eve= nt Notifications

draft-gonzalez-netconf-event-notifications 

 

RESTCONF & HTTP Trans= port for Event Notifications

draft-voit-netconf-restconf-notif

 

Thanks!

Eric (on behalf of the authors and contributors)

--_000_09d23b6a25784819b933f433b733c47dXCHRTP013ciscocom_-- From nobody Wed Jul 13 13:58:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE33612D88B for ; Wed, 13 Jul 2016 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ25EZ5yafin for ; Wed, 13 Jul 2016 13:58:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454F612D89A for ; Wed, 13 Jul 2016 13:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34051; q=dns/txt; s=iport; t=1468443502; x=1469653102; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H2jsxK5jRNlXHDWKuHESAl9Wu3B7sZe5BlB49cQpfKA=; b=Dc4S8sq+GouMKPkwc9kw3nB4gcODuvnryrvvmTR35YI1o4POMnq//kwc cAxnu996skUeWFZbHg7hlKR1NVzS4+hRPCQNmQd6ad9MqyVNSX5IwdiNj G+wuqS4BZRQvWAd9W6TVTpT3Con13I+o3KElYsyhF/l2rs12Aqm75AqsA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgAnq4ZX/5ldJa1bgnBOVnwGrEuMF?= =?us-ascii?q?4F7JIUrSgKBNjgUAQEBAQEBAWUnhF0BBQEBbAsQAgEIDioBBgchBgsUEQIEAQ0?= =?us-ascii?q?FiBYDFw69CA2EIwEBAQEBAQEBAQEBAQEBAQEBAQEBARyIIoJVgkOBaEyCdoIvB?= =?us-ascii?q?YgnhWCBNIQjhQo0AYYQhjCCFoI5jHaIH4d3AR42g3FuAYg3fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,359,1464652800"; d="scan'208,217";a="129192653" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2016 20:58:01 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6DKw15Z030383 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 20:58:01 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 13 Jul 2016 16:58:00 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1210.000; Wed, 13 Jul 2016 16:58:00 -0400 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani , Netconf Thread-Topic: [Netconf] What should a server response be? Thread-Index: AQHR27WOBb38VRwq7UGCB4eO+lxARqAVQJyAgACbhwCAAUH5gA== Date: Wed, 13 Jul 2016 20:58:00 +0000 Message-ID: References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> In-Reply-To: <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.214.171] Content-Type: multipart/alternative; boundary="_000_A49BD9BCD9B84ECABCBDCCA3F4A17AF8ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] What should a server response be? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:58:26 -0000 --_000_A49BD9BCD9B84ECABCBDCCA3F4A17AF8ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'd like to call out a second example and provide my interpretation. It is = also an ODL-based interaction, but with a different request. For reference,= the model being used in my example is the same one as Mahesh's, and if peo= ple want more context the source may be found here: https://github.com/einarnn/yang/blob/611-early-access/vendor/cisco/xr/611/C= isco-IOS-XR-l2vpn-cfg.yang The first request is: none The request only contains empty non-presence containers, and the salient po= ints here seem to be that the default operation is none, but this is overri= dden at the l2vpn node with merge. I believe that this means the three leve= ls of container should be considered as "created" in the context of the can= didate config we are working on. The second request is: none SERVICE ESP-vPE1 Bundle-Ether46001.1 Again, the default operation is none, and in this request it is not overrid= den until the container "bridge-domain-group", with replace. This request b= uilds on the first request, and from reading RFC 6241 it seems to me that a= commit after receiving the second request should (with no other problems) = succeed. It may be a slightly odd pattern that ODL is exhibiting here, but I believe= it should work with no issues. Cheers, Einar On Jul 13, 2016, at 2:45 AM, Mahesh Jethanandani > wrote: On Jul 12, 2016, at 9:28 AM, Xiang Li > wrote: On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote: The Opendaylight controller is constructing this particular set of requests as part of a single transaction. The response of the server = is to reject the configuration that the particular node (evpn container) do= es not exist. However, if the default-operation=3Dnone is removed or changed to replace, = the server responds with an RPC OK. Is the server right in its interpretation of what RFC 6241 says? In particu= lar, the way the server is interpreting this request is as follows from Sec= tion 7.2 of the RFC: none: The target datastore is unaffected by the configuration in the parameter, unless and until the incoming configuration data uses the "operation" attribute to request a different operation. If the configuration in the parameter contains data for which there is not a corresponding level in the target datastore, an is returned with an value of data-missing. Using "none" allows operations like "delete" to avoid unintentionally creating the parent hierarchy of the element to be deleted. and then this: operation: Elements in the subtree MAY contain an "operation" attribute, which belongs to the NETCONF namespace defined in Section 3.1. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the subtree. 1st request: rollback-on-error http:= //cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"> ## The container evpn in this case is a non-presence container and does not co= ntain any mandatory leafs or default statements. The server therefore inter= prets that nothing has to be done here, as it is not required to create a e= mpty container. I think the container node needs to be created when you are merging to crea= te new nodes explicitly. RFC6020 7.5. The container Statement 7.5.8. NETCONF Operations When a NETCONF server processes an request, the elements of procedure for the container node are: If the operation is "merge" or "replace", the node is created if it does not exist. It makes no sense to me for the server to return ok but actually does not c= reate that container node in this case. And that is the clarification I am seeking. Note, it is an empty non-presen= ce container. Should the server create this empty container, and if so how = would it be represented in the config tree? In this particular case, the re= quest is followed by child nodes. What happens if no child nodes are create= d? The server may delete an empty container node but only when you deleting st= uff: If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container. For a delete it is clear. But the RFC is silent for a create (and the defau= lt operation of merge). If a non-presence empty container can be deleted, w= hy should it be created? Thanks. 2nd request: none rollback-on-error http:= //cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"> ## In the second request, the default-operation=3Dnone again seems to imply th= at nothing needs to be done for creation of the evpn node. Therefore by the= time the evpn-load-balancing request rolls around, the request is rejected= as the parent container does not exist. As stated earlier, if the default-= operation is removed (causing a default of merge) or replaced with a replac= e, the transaction succeeds. A second interpretation to this transaction is that the server should have = created the evpn node as part of the first request, and that the none opera= tion was implying that the node had already been created. If the server returns ok for the first , then it means it has = successfully created the top two container nodes in the hierarchy: then the second request should have succeeded. -Xiang Li Mahesh Jethanandani mjethanandani@gmail.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_A49BD9BCD9B84ECABCBDCCA3F4A17AF8ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <705B8A33CB67684BB1B374A3D16A0588@emea.cisco.com> Content-Transfer-Encoding: quoted-printable I'd like to call out a second example and provide my interpretation. It is = also an ODL-based interaction, but with a different request. For reference,= the model being used in my example is the same one as Mahesh's, and if peo= ple want more context the source may be found here:

https://g= ithub.com/einarnn/yang/blob/611-early-access/vendor/cisco/xr/611/Cisco-IOS-= XR-l2vpn-cfg.yang

The first request is:
<?xml version=3D"1.0" encoding=3D&quo=
t;UTF-8"?>
<nc:rpc xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" m=
essage-id=3D"...">
  <nc:edit-config>
    <nc:target>
      <nc:candidate/>
    </nc:target>
    <nc:default-operation>none</nc:default-operation=
>
    <config>
      <l2vpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg" nc:operation=3D"merge">
         <database>
           <bridge-domain-groups/>
         </database>
      </l2vpn>
    </config>
  </nc:edit-config>
</nc:rpc>
The request only contains empty non-presence containers, an= d the salient points here seem to be that the default operation is none, but this is overridden at the l2vpn node with merge. I believe that this means the three levels of container= should be considered as "created" in the context of the candidat= e config we are working on.

The second request is:
<?xml version=3D"1.0" encoding=3D&quo=
t;UTF-8"?>
<nc:rpc xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" m=
essage-id=3D"...">
  <nc:edit-config>
    <nc:target>
      <nc:candidate/>
    </nc:target>
    <nc:default-operation>none</nc:default-operation=
>
    <config>
      <l2vpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
        <database>
          <bridge-domain-groups>
            <bridge-domain-group nc:operation=3D"repl=
ace">
              <name>SERVICE</name>
              <bridge-domains>
                <bridge-domain>
                  <name>ESP-vPE1</name>
                  <bd-attachment-circuits>
                    <bd-attachment-circuit>
                      <name>Bundle-Ether46001.1</name>
                    </bd-attachment-circuit>
                  </bd-attachment-circuits>
                </bridge-domain>
              </bridge-domains>
            </bridge-domain-group>
          </bridge-domain-groups>
        </database>
      </l2vpn>
    </config>
  </nc:edit-config>
</nc:rpc>
Again, the default operation is none, and= in this request it is not overridden until the container "bridge-doma= in-group", with replace. This request builds on the first request, and fr= om reading RFC 6241 it seems to me that a commit after receiving the second= request should (with no other problems) succeed.

It may be a slightly odd pattern that ODL is exhibiting her= e, but I believe it should work with no issues.

Cheers,

Einar


On Jul 13, 2016, at 2:45 AM, Mahesh Jethanandani <mjethanandani@gmail.com= > wrote:


On Jul 12, 2016, at 9:28 AM, Xiang Li <xiangli@seguesoft.com> wrote:
On 7/11/2016 3:47 PM, Mahesh Jethanandani wr= ote:
The Opendaylight controller is constructing this particular= set of <edit-config> requests as part of a single transaction. The r= esponse of the server is to reject the configuration that the particular no= de (evpn container) does not exist. 

However, if the default-operation=3Dnone is removed or chan= ged to replace, the server responds with an RPC OK.

Is the server right in its interpretation of what RFC 6241 = says? In particular, the way the server is interpreting this request is as = follows from Section 7.2 of the RFC:

         none:  <=
font class=3D"" color=3D"#b51a00">The target datastore is unaffected by the=
 configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to =
request
            a different operation.  If the configuration in the <=
config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error&g=
t;
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete"=
; to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and then this:

      operation: =
 Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF name=
space
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


1st request:
 
<rpc xmlns=3D"urn:ietf:params= :xml:ns:netconf:base:1.0" message-id=3D"m-23">
  <edit-config>
    <target>
      <ca= ndidate/>
    </target>
    <error-option&g= t;rollback-on-error</error-option>
    <config>
      <ev= pn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
      &= nbsp; <evpn-tables/>
      </e= vpn>
    </config>
  </edit-config>
</rpc>
##
 
The container evpn in t= his case is a non-presence container and does not contain any mandatory lea= fs or default statements. The server therefore interprets that nothing has = to be done here, as it is not required to create a empty container.
 


I think the container node needs to be created when you are merging to crea= te new nodes explicitly.
RFC6020
7.5.  The container Statement
   7.5.8.  NETCONF <edit-config> Operations
    When a NETCONF server processes an <ed=
it-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the nod=
e is created if
      it does not exist.
It makes no sense to me for the server to return ok but actually does not c= reate that
container node in this case.

And that is the clarification I am seeking. Note, it is an empty non-presen= ce container. Should the server create this empty container, and if so how = would it be represented in the config tree? In this particular case, the re= quest is followed by child nodes. What happens if no child nodes are created?



The server may delete an empty container node but only when you deleting st= uff:

If a container does not h=
ave a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

For a delete it is clear. But the RFC is silent for a create (and the defau= lt operation of merge). If a non-presence empty container can be deleted, w= hy should it be created?

Thanks.

2nd request:
 
<rpc xmlns=3D"urn:ietf:params= :xml:ns:netconf:base:1.0" message-id=3D"m-24">
  <edit-config>
    <target>
      <ca= ndidate/>
    </target>
    <de= fault-operation>none</default-operation>
    <error-option&g= t;rollback-on-error</error-option>
    <config>
      <ev= pn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
      &= nbsp; <evpn-tables>
      &= nbsp;   <evpn-load-balancing xmlns:a=3D"urn:ietf:params:x= ml:ns:netconf:base:1.0" a:operation=3D"replace">
      &= nbsp;     <enable/><= /div>
      &= nbsp;     <evpn-flow-label/>
      &= nbsp;   </evpn-load-balancing>=
      &= nbsp; </evpn-tables>
      </e= vpn>
    </config>
  </edit-config>
</rpc>
##

In the second request, the default-operation=3Dnone again s= eems to imply that nothing needs to be done for creation of the evpn node. = Therefore by the time the evpn-load-balancing request rolls around, the req= uest is rejected as the parent container does not exist. As stated earlier, if the default-operation is removed (ca= using a default of merge) or replaced with a replace, the transaction succe= eds.

A second interpretation to this transaction is that the ser= ver should have created the evpn node as part of the first request, and tha= t the none operation was implying that the node had already been created.



If the server returns ok for the first <edit-config>, then it means i= t has successfully created the top two container nodes in the hierarchy:
      <ev= pn >
     &= nbsp;  <evpn-tables>

then the second request should have succeeded.


-Xiang Li

Mahesh Jethanandani
mjeth= anandani@gmail.com



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

--_000_A49BD9BCD9B84ECABCBDCCA3F4A17AF8ciscocom_-- From nobody Wed Jul 13 14:32:28 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9EC12D950 for ; Wed, 13 Jul 2016 14:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4A4GMuVRZGj for ; Wed, 13 Jul 2016 14:32:23 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB17F12D935 for ; Wed, 13 Jul 2016 14:32:07 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id t190so22279395pfb.3 for ; Wed, 13 Jul 2016 14:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=uoKJpvwhg2JbTndNF3W6i5wnnI0ITs+fipP6wii4C+o=; b=qm4I/+LtBZ9rfui/FLkfz1YcFYYagVP3CI0TaoJ2TGLCF3H2b1tHvi+bSLgvK/YHsM okned1GlVjK8yKkClL/5QmJ2z2z9jGE5UX/MUAjw2Np9FWBbR+MPl4l9tVddbnh4jRMg a2YRwyziuQDPc4t/XFkZ55XdXjZ0gcq08ASIOMUE9942HoxmkpZU3geWk0fQUDS4xgPC DKKUbw4A/CnupCY5imZBr7mRCbmCL0FF0rHbzgJzc+lDVpkVEXCFjYXpxtv6CNFy5LZN FE8jupX3VnsaRSfz20dSr79/BG67DXE4y3vgXazurGXdURLKl6om0/VgV7nSdqyS70jy zLrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uoKJpvwhg2JbTndNF3W6i5wnnI0ITs+fipP6wii4C+o=; b=SrqYIPBpxnCLgnXDzSrjEnY/wtkTEt2mT9DNNMfd0z2rYTrmilgSohTSNYOjg7yQpQ G3k/a495o9OjSHxnHo6+FpX3J+4tVhtjvxnzc/S/BvVCCazpPhvI2SOTEm6cparQksvI 2yyDDwaIBpSj1hQyD2YJaSSVR5hzSfDRFxjnQ8fSU77aRuxDfwSkYqbjGvkDZlzaC1zA 7X+o/KG99/dLxIE1I6AmoifkzRBlUkuCwk2UgOFyogNbZ3vGEWDnYT/qE7L5jaYqIbXL MQLdr5NWPaHp2aQV1FfrW/jB5mj7lv+UnAYa7+TWBsFfPiUpL9IdET4Ol2E67Y5ObTn1 gpLg== X-Gm-Message-State: ALyK8tJfsAz6qQWTAy4CKFKdE0j95InMNAoPInxnxZQhD+HP5WlOG1BVMMOHeL8ismQPAw== X-Received: by 10.98.25.8 with SMTP id 8mr7084520pfz.94.1468445527551; Wed, 13 Jul 2016 14:32:07 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1001::6c0? ([2001:420:c0c8:1001::6c0]) by smtp.gmail.com with ESMTPSA id e14sm5182532pfb.89.2016.07.13.14.31.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jul 2016 14:32:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_57EC4E67-B1AC-42C0-96C1-1252F90B6527" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Giles Heron In-Reply-To: Date: Wed, 13 Jul 2016 14:31:55 -0700 Message-Id: References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> To: "Einar Nilsen-Nygaard (einarnn)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netconf-dev@lists.opendaylight.org, Netconf Subject: Re: [Netconf] What should a server response be? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:32:26 -0000 --Apple-Mail=_57EC4E67-B1AC-42C0-96C1-1252F90B6527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Einar, > On 13 Jul 2016, at 13:58, Einar Nilsen-Nygaard (einarnn) = wrote: >=20 > I'd like to call out a second example and provide my interpretation. = It is also an ODL-based interaction, but with a different request. For = reference, the model being used in my example is the same one as = Mahesh's, and if people want more context the source may be found here: >=20 > = https://github.com/einarnn/yang/blob/611-early-access/vendor/cisco/xr/611/= Cisco-IOS-XR-l2vpn-cfg.yang = >=20 > The first request is: > > > > > > > none > > " nc:operation=3D"merge">= > > > > > > > > The request only contains empty non-presence containers, and the = salient points here seem to be that the default operation is none, but = this is overridden at the l2vpn node with merge. I believe that this = means the three levels of container should be considered as "created" in = the context of the candidate config we are working on. >=20 > The second request is: > > > > > > > none > > "> > > > > SERVICE > > > ESP-vPE1 > > > Bundle-Ether46001.1 > > > > > > > > > > > > Again, the default operation is none, and in this request it is not = overridden until the container "bridge-domain-group", with replace. This = request builds on the first request, and from reading RFC 6241 it seems = to me that a commit after receiving the second request should (with no = other problems) succeed. >=20 > It may be a slightly odd pattern that ODL is exhibiting here, but I = believe it should work with no issues. agreed on both counts. I pinged the ODL netconf-dev mailing list (CCed) a week ago to ask why = the change from merge to replace. I=92ve not heard back but maybe = someone will respond this time... Giles > Cheers, >=20 > Einar >=20 >=20 >> On Jul 13, 2016, at 2:45 AM, Mahesh Jethanandani = > wrote: >>=20 >>=20 >>> On Jul 12, 2016, at 9:28 AM, Xiang Li > wrote: >>>=20 >>> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote: >>>> The Opendaylight controller is constructing this particular set of = requests as part of a single transaction. The response of = the server is to reject the configuration that the particular node (evpn = container) does not exist.=20 >>>>=20 >>>> However, if the default-operation=3Dnone is removed or changed to = replace, the server responds with an RPC OK. >>>>=20 >>>> Is the server right in its interpretation of what RFC 6241 says? In = particular, the way the server is interpreting this request is as = follows from Section 7.2 of the RFC: >>>>=20 >>>> none: The target datastore is unaffected by the = configuration >>>> in the parameter, unless and until the = incoming >>>> configuration data uses the "operation" attribute to = request >>>> a different operation. If the configuration in the = >>>> parameter contains data for which there is not a >>>> corresponding level in the target datastore, an = >>>> is returned with an value of data-missing. >>>> Using "none" allows operations like "delete" to avoid >>>> unintentionally creating the parent hierarchy of the = element >>>> to be deleted. >>>>=20 >>>> and then this: >>>>=20 >>>> operation: Elements in the subtree MAY contain an >>>> "operation" attribute, which belongs to the NETCONF = namespace >>>> defined in Section 3.1 = . The attribute = identifies the point in >>>> the configuration to perform the operation and MAY appear = on >>>> multiple elements throughout the subtree. >>>>=20 >>>>=20 >>>> 1st request: >>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> rollback-on-error >>>> >>>> http://cisco.com/ns/yang/= Cisco-IOS-XR-l2vpn-cfg = "> >>>> >>>> >>>> >>>> >>>> >>>> ## >>>> =20 >>>> The container evpn in this case is a non-presence container and = does not contain any mandatory leafs or default statements. The server = therefore interprets that nothing has to be done here, as it is not = required to create a empty container. >>>> =20 >>>=20 >>>=20 >>> I think the container node needs to be created when you are merging = to create new nodes explicitly. >>> RFC6020=20 >>> 7.5. The container Statement >>> 7.5.8. NETCONF Operations >>> When a NETCONF server processes an request, the >>> elements of procedure for the container node are: >>>=20 >>> If the operation is "merge" or "replace", the node is created = if >>> it does not exist. >>>=20 >>> It makes no sense to me for the server to return ok but actually = does not create that >>> container node in this case. >>=20 >> And that is the clarification I am seeking. Note, it is an empty = non-presence container. Should the server create this empty container, = and if so how would it be represented in the config tree? In this = particular case, the request is followed by child nodes. What happens if = no child nodes are created? >>=20 >>>=20 >>>=20 >>> The server may delete an empty container node but only when you = deleting stuff: >>>=20 >>> If a container does not have a "presence" statement and the last >>> child node is deleted, the NETCONF server MAY delete the = container. >>=20 >> For a delete it is clear. But the RFC is silent for a create (and the = default operation of merge). If a non-presence empty container can be = deleted, why should it be created? >>=20 >> Thanks. >>=20 >>>=20 >>>=20 >>>> 2nd request: >>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> none >>>> rollback-on-error >>>> >>>> http://cisco.com/ns/yang/= Cisco-IOS-XR-l2vpn-cfg = "> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ## >>>>=20 >>>> In the second request, the default-operation=3Dnone again seems to = imply that nothing needs to be done for creation of the evpn node. = Therefore by the time the evpn-load-balancing request rolls around, the = request is rejected as the parent container does not exist. As stated = earlier, if the default-operation is removed (causing a default of = merge) or replaced with a replace, the transaction succeeds. >>>>=20 >>>> A second interpretation to this transaction is that the server = should have created the evpn node as part of the first request, and that = the none operation was implying that the node had already been created. >>>>=20 >>>=20 >>>=20 >>> If the server returns ok for the first , then it means = it has successfully created the top two container nodes in the = hierarchy: >>>=20 >>> >>> >>>=20 >>> then the second request should have succeeded. >>>=20 >>>=20 >>> -Xiang Li >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_57EC4E67-B1AC-42C0-96C1-1252F90B6527 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Einar,

On 13 Jul 2016, at 13:58, Einar = Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:

I'd like to call out a second example and provide my interpretation. It = is also an ODL-based interaction, but with a different request. For = reference, the model being used in my example is the same one as = Mahesh's, and if people want more context the source may be found here:

https://github.com/einarnn/yang/blob/611-early-access/vendor/ci= sco/xr/611/Cisco-IOS-XR-l2vpn-cfg.yang

The first request is:
<?xml version=3D"1.0" =
encoding=3D"UTF-8"?>
<nc:rpc xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" =
message-id=3D"...">
  <nc:edit-config>
    <nc:target>
      <nc:candidate/>
    </nc:target>
    <nc:default-operation>none</nc:default-operation>
    <config>
      <l2vpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg" nc:operation=3D"merge">
         <database>
           <bridge-domain-groups/>
         </database>
      </l2vpn>
    </config>
  </nc:edit-config>
</nc:rpc>
The request only contains empty non-presence containers, = and the salient points here seem to be that the default operation is none, but this is overridden at the l2vpn node with merge. I believe that this means the three levels of = container should be considered as "created" in the context of the = candidate config we are working on.

The second request is:
<?xml version=3D"1.0" =
encoding=3D"UTF-8"?>
<nc:rpc xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0" =
message-id=3D"...">
  <nc:edit-config>
    <nc:target>
      <nc:candidate/>
    </nc:target>
    <nc:default-operation>none</nc:default-operation>
    <config>
      <l2vpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
        <database>
          <bridge-domain-groups>
            <bridge-domain-group nc:operation=3D"replace">
              <name>SERVICE</name>
              <bridge-domains>
                <bridge-domain>
                  <name>ESP-vPE1</name>
                  <bd-attachment-circuits>
                    <bd-attachment-circuit>
                      <name>Bundle-Ether46001.1</name>
                    </bd-attachment-circuit>
                  </bd-attachment-circuits>
                </bridge-domain>
              </bridge-domains>
            </bridge-domain-group>
          </bridge-domain-groups>
        </database>
      </l2vpn>
    </config>
  </nc:edit-config>
</nc:rpc>
Again, the default operation is none, = and in this request it is not overridden until the container = "bridge-domain-group", with replace. This request builds on the first request, and = from reading RFC 6241 it seems to me that a commit after receiving the = second request should (with no other problems) succeed.

It may be a slightly odd pattern that ODL is exhibiting = here, but I believe it should work with no = issues.

agreed on both counts.

I pinged the ODL netconf-dev mailing list (CCed) a = week ago to ask why the change from merge to replace.   I=92ve not = heard back but maybe someone will respond this time...

Giles

Cheers,

Einar


On Jul 13, 2016, at 2:45 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:


On Jul 12, 2016, at 9:28 AM, Xiang Li <xiangli@seguesoft.com> wrote:

On 7/11/2016 3:47 PM, Mahesh Jethanandani = wrote:
The Opendaylight controller is constructing this = particular set of <edit-config> requests as part of a single = transaction. The response of the server is to reject the configuration = that the particular node (evpn container) does not exist. 

However, if the default-operation=3Dnone is removed or = changed to replace, the server responds with an RPC OK.

Is the server right in its interpretation of what RFC = 6241 says? In particular, the way the server is interpreting this = request is as follows from Section 7.2 of the RFC:

         none:  The target datastore is unaffected by the =
configuration
            in the <config> parameter, unless and until the =
incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the =
<config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an =
<rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and then this:

      operation:  Elements in the =
<config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The =
attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


1st request:
 
<rpc = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" = message-id=3D"m-23">
  = <edit-config>
    = <target>
      <candidate/>
    = </target>
    = <error-option>rollback-on-error</error-option>
    = <config>
      <evpn xmlns=3D"http://cisco.com/= ns/yang/Cisco-IOS-XR-l2vpn-cfg">
=
        = <evpn-tables/>
      </evpn>
    = </config>
  = </edit-config>
</rpc>
##
 
The container evpn = in this case is a non-presence container and does not contain any = mandatory leafs or default statements. The server therefore interprets = that nothing has to be done here, as it is not required to create a empty container.
 


I think the container node needs to be created when you are merging to = create new nodes explicitly.
RFC6020
7.5.  The container Statement
   7.5.8.  NETCONF <edit-config> Operations
    When a NETCONF server processes an =
<edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.
It makes no sense to me for the server to return ok but actually does = not create that
container node in this case.

And that is the clarification I am seeking. Note, it is an empty = non-presence container. Should the server create this empty container, = and if so how would it be represented in the config tree? In this = particular case, the request is followed by child nodes. What happens if no child nodes are created?



The server may delete an empty container node but only when you deleting = stuff:

If a container does not have a =
"presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

For a delete it is clear. But the RFC is silent for a create (and the = default operation of merge). If a non-presence empty container can be = deleted, why should it be created?

Thanks.









2nd request:


 


<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0" =
message-id=3D"m-24">


  =
<edit-config>


    =
<target>


      <candidate/>


    =
</target>


    =
<default-operation>none</default-operation>


    =
<error-option>rollback-on-error</error-option>


    =
<config>


      <evpn xmlns=3D"http://cisco.com/=
ns/yang/Cisco-IOS-XR-l2vpn-cfg">
=


        =
<evpn-tables>


          =
<evpn-load-balancing =
xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1.0" =
a:operation=3D"replace">


            =
<enable/>


            =
<evpn-flow-label/>


          =
</evpn-load-balancing>


        =
</evpn-tables>


      </evpn>


    =
</config>


  =
</edit-config>


</rpc>


##





In the second request, the default-operation=3Dnone =
again seems to imply that nothing needs to be done for creation of the =
evpn node. Therefore by the time the evpn-load-balancing request rolls =
around, the request is rejected as the parent container
 does not exist. As stated earlier, if the default-operation is removed =
(causing a default of merge) or replaced with a replace, the transaction =
succeeds.







A second interpretation to this transaction is that the =
server should have created the evpn node as part of the first request, =
and that the none operation was implying that the node had already been =
created.
















If the server returns ok for the first <edit-config>, then it =
means it has successfully created the top two container nodes in the =
hierarchy:




      <evpn >

        <evpn-tables>



then the second request should have succeeded.














-Xiang Li


















Mahesh Jethanandani


mjethanandani@gmail.com














_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf
















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

=

--Apple-Mail=_57EC4E67-B1AC-42C0-96C1-1252F90B6527--


From nobody Wed Jul 13 14:55:47 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E948112D85C for ; Wed, 13 Jul 2016 14:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 ZX2gFgmktgoQ for ; Wed, 13 Jul 2016 14:55:43 -0700 (PDT)
Received: from p3plsmtpa12-02.prod.phx3.secureserver.net (p3plsmtpa12-02.prod.phx3.secureserver.net [68.178.252.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C36C12D68B for ; Wed, 13 Jul 2016 14:55:43 -0700 (PDT)
Received: from [192.168.10.101] ([24.13.90.46]) by p3plsmtpa12-02.prod.phx3.secureserver.net with  id JMvi1t006100Es801MvitA; Wed, 13 Jul 2016 14:55:43 -0700
From: Xiang Li 
To: Mahesh Jethanandani 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com>
Message-ID: <5786B8CE.3040507@seguesoft.com>
Date: Wed, 13 Jul 2016 16:55:26 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com>
Content-Type: multipart/alternative; boundary="------------060703030404090903030908"
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2016 21:55:46 -0000

This is a multi-part message in MIME format.
--------------060703030404090903030908
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>
>> On Jul 12, 2016, at 9:28 AM, Xiang Li  wrote:
>>
>> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
>>> The Opendaylight controller is constructing this particular set of 
>>>  requests as part of a single transaction. The response 
>>> of the server is to reject the configuration that the particular 
>>> node (evpn container) does not exist.
>>>
>>> However, if the default-operation=none is removed or changed to 
>>> replace, the server responds with an RPC OK.
>>>
>>> Is the server right in its interpretation of what RFC 6241 says? In 
>>> particular, the way the server is interpreting this request is as 
>>> follows from Section 7.2 of the RFC:
>>>
>>>           none:The target datastore is unaffected by the configuration in the 
>>>  parameter, unless and until the incoming configuration data 
>>> uses the "operation" attribute to request a different operation.   If the configuration in the 
>>>              parameter contains data for which there is not a
>>>              corresponding level in the target datastore, an 
>>>              is returned with an  value of data-missing.
>>>              Using "none" allows operations like "delete" to avoid
>>>              unintentionally creating the parent hierarchy of the element
>>>              to be deleted.
>>>
>>> and then this:
>>>
>>>        operation:  Elements in the  subtree MAY contain an
>>>           "operation" attribute, which belongs to the NETCONF namespace
>>>           defined inSection 3.1 .The attribute identifies the point in the configuration to perform 
>>> the operation and MAY appear on multiple elements throughout the 
>>>  subtree.
>>>
>>>
>>> *_1^st  request:_*
>>> 
>>>   
>>>     
>>>       
>>>     
>>> rollback-on-error
>>>     
>>>       
>>>         
>>>       
>>>     
>>>   
>>> 
>>> ##
>>> The container evpn in this case is a non-presence container and does 
>>> not contain any mandatory leafs or default statements. The server 
>>> therefore interprets that nothing has to be done here, as it is not 
>>> required to create a empty container.
>>
>>
>> I think the container node needs to be created when you are merging 
>> to create new nodes explicitly.
>> RFC6020
>> 7.5.  The container Statement
>>    7.5.8.  NETCONF  Operations
>>      When a NETCONF server processes an  request, the
>>      elements of procedure for the container node are:
>>
>>        If the operation is "merge" or "replace", the node is created if
>>        it does not exist.
>>
>> It makes no sense to me for the server to return ok but actually does 
>> not create that
>> container node in this case.
>
> And that is the clarification I am seeking. Note, it is an empty 
> non-presence container. Should the server create this empty container, 
> and if so how would it be represented in the config tree? In this 
> particular case, the request is followed by child nodes. What happens 
> if no child nodes are created?
>

My understanding is that it does not matter if it is a presence 
container or not in this case
, nor if there are child nodes included  to be created.


>>
>>
>> The server may delete an empty container node but only when you 
>> deleting stuff:
>>
>> If a container does not have a "presence" statement and the last
>>     child node is deleted, the NETCONF server MAY delete the container.
>
> For a delete it is clear. But the RFC is silent for a create (and the 
> default operation of merge).

I think RFC6020 7.5.8.  "NETCONF  Operations" (for 
container node)
covers this :

-    When a NETCONF server processes an  request, the
-    elements of procedure for the container node are:
-
-      If the operation is "merge" or "replace", the node is created if
-      it does not exist.
      
-      If the operation is "create", the node is created if it does not
-      exist.  If the node already exists, a "data-exists" error is
-      returned.



> If a non-presence empty container can be deleted, why should it be 
> created?


It is because the client is sending an   to create this 
container explicitly.
If a client wants to create *only* a container node, it can certainly do 
so without
having to specify any child instance nodes. If the server returns "Ok" 
for such
a request then it must mean it has indeed created the container node.

I think it makes little sense for a server to return "Ok" but does not 
create
the container node (thinking nothing needs to be done if there are no 
child nodes
included in the same request). The "Ok" response must mean something, i.e.,
the create/merge/replace operations has actually succeeded in creating the
container node in question.

-Xiang

>
> Thanks.
>
>>
>>> *_2^nd  request:_*
>>> 
>>>   
>>>     
>>>       
>>>     
>>> none
>>> rollback-on-error
>>>     
>>>       
>>>         
>>>           >> xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
>>>             
>>>             
>>>           
>>>         
>>>       
>>>     
>>>   
>>> 
>>> ##
>>>
>>> In the second request, the default-operation=none again seems to 
>>> imply that nothing needs to be done for creation of the evpn node. 
>>> Therefore by the time the evpn-load-balancing request rolls around, 
>>> the request is rejected as the parent container does not exist. As 
>>> stated earlier, if the default-operation is removed (causing a 
>>> default of merge) or replaced with a replace, the transaction succeeds.
>>>
>>> A second interpretation to this transaction is that the server 
>>> should have created the evpn node as part of the first request, and 
>>> that the none operation was implying that the node had already been 
>>> created.
>>>
>>
>>
>> If the server returns ok for the first , then it means 
>> it has successfully created the top two container nodes in the hierarchy:
>>
>> 
>> 
>>
>> then the second request should have succeeded.
>>
>>
>> -Xiang Li
>
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>
>
>

--------------060703030404090903030908
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/12/2016 8:45 PM, Mahesh
      Jethanandani wrote:

    

    

      
      

      

        

          
On Jul 12, 2016, at 9:28 AM, Xiang Li <xiangli@seguesoft.com>
            wrote:

          

          

            
            

              
On 7/11/2016 3:47 PM, Mahesh
                Jethanandani wrote:

              

              

                
                
The Opendaylight controller is
                  constructing this particular set of
                  <edit-config> requests as part of a single
                  transaction. The response of the server is to reject
                  the configuration that the particular node (evpn
                  container) does not exist. 

                


                

                
However, if the default-operation=none is
                  removed or changed to replace, the server responds
                  with an RPC OK.

                


                

                
Is the server right in its interpretation
                  of what RFC 6241 says? In particular, the way the
                  server is interpreting this request is as follows from
                  Section 7.2 of the RFC:

                


                

                

                  
         none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


                

                


                

                
and then this:

                


                

                

                  
      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


                

                


                

                


                

                

                  
1st request:

                  
 

                  
<rpc
                      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
                      message-id="m-23">

                  
  <edit-config>

                  
    <target>

                  
      <candidate/>

                  
    </target>

                  
   
                      <error-option>rollback-on-error</error-option>

                  
    <config>

                  
                  
        <evpn-tables/>

                  
      </evpn>

                  
    </config>

                  
  </edit-config>

                  
</rpc>

                  
##

                  
 

                  
The
                    container evpn in this case is a non-presence
                    container and does not contain any mandatory leafs
                    or default statements. The server therefore
                    interprets that nothing has to be done here, as it
                    is not required to create a empty container.

                  
 

                

              

              

              

              I think the container node needs to be created when you
              are merging to create new nodes explicitly.

              RFC6020 

              7.5.  The container Statement

                 7.5.8.  NETCONF <edit-config> Operations

              
    When a NETCONF server processes an <edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.



              It makes no sense to me for the server to return ok but
              actually does not create that

              container node in this case.

            

          

        

        


        

        And that is the clarification I am seeking. Note, it is an empty
        non-presence container. Should the server create this empty
        container, and if so how would it be represented in the config
        tree? In this particular case, the request is followed by child
        nodes. What happens if no child nodes are created?

      


      

    

    

    My understanding is that it does not matter if it is a presence
    container or not in this case

    , nor if there are child nodes included  to be created.

    

    

    

      

        

          

            
 

              

              The server may delete an empty container node but only
              when you deleting stuff:

              

              
If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.


            

          

        

        


        

        For a delete it is clear. But the RFC is silent for a create
        (and the default operation of merge).

    

    

    I think RFC6020 7.5.8.  "NETCONF <edit-config> Operations"
    (for container node)

    covers this :
    
-    When a NETCONF server processes an <edit-config> request, the
-    elements of procedure for the container node are:
-
-      If the operation is "merge" or "replace", the node is created if
-      it does not exist.
     
-      If the operation is "create", the node is created if it does not
-      exist.  If the node already exists, a "data-exists" error is
-      returned.


    

    

    

      
 If a non-presence empty container can be deleted, why should
        it be created?

    

    

    

    It is because the client is sending an <edit-config>  to
    create this container explicitly.

    If a client wants to create *only* a container node, it can
    certainly do so without 

    having to specify any child instance nodes. If the server returns
    "Ok" for such

    a request then it must mean it has indeed created the container
    node.

    

    I think it makes little sense for a server to return "Ok" but does
    not create 

    the container node (thinking nothing needs to be done if there are
    no child nodes

    included in the same request). The "Ok" response must mean
    something, i.e.,

    the create/merge/replace operations has actually succeeded in
    creating the 

    container node in question.

    

    -Xiang

    

    

      


      

      
Thanks.

      


        

          

            

              

              

              

                

                  
2nd request:

                  
 

                  
<rpc
                      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
                      message-id="m-24">

                  
  <edit-config>

                  
    <target>

                  
      <candidate/>

                  
    </target>

                  
   
                      <default-operation>none</default-operation>

                  
   
                      <error-option>rollback-on-error</error-option>

                  
    <config>

                  
                  
        <evpn-tables>

                  
          <evpn-load-balancing
                      xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0"
                      a:operation="replace">

                  
            <enable/>

                  
            <evpn-flow-label/>

                  
          </evpn-load-balancing>

                  
        </evpn-tables>

                  
      </evpn>

                  
    </config>

                  
  </edit-config>

                  
</rpc>

                  
##

                  


                    
In the second request, the
                      default-operation=none again seems to imply that
                      nothing needs to be done for creation of the evpn
                      node. Therefore by the time the
                      evpn-load-balancing request rolls around, the
                      request is rejected as the parent container does
                      not exist. As stated earlier, if the
                      default-operation is removed (causing a default of
                      merge) or replaced with a replace, the transaction
                      succeeds.

                    


                    

                    
A second interpretation to this
                      transaction is that the server should have created
                      the evpn node as part of the first request, and
                      that the none operation was implying that the node
                      had already been created.

                    


                    

                  

                

              

              

              

              If the server returns ok for the first
              <edit-config>, then it means it has successfully
              created the top two container nodes in the hierarchy:

              

              
     
                  <evpn >

                     
                <evpn-tables>

                

                then the second request should have succeeded.

          

        

        

          

            
 

              

              -Xiang Li

              
 

            

          

        

      

      

      

        
Mahesh Jethanandani

        
        


        

        

      

      

    

  


--------------060703030404090903030908--


From nobody Wed Jul 13 14:58:39 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D957D12D8D6 for ; Wed, 13 Jul 2016 14:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9oVqel5rIa for ; Wed, 13 Jul 2016 14:58:34 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3B512D67B for ; Wed, 13 Jul 2016 14:58:33 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id j126so30735789vkg.3 for ; Wed, 13 Jul 2016 14:58:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=19F8TjalytgDYersRnsunHYzseurAeLnjqlnaPjb9vo=; b=ulHfP0hKSomeKmfu4gqU1dg68pPJotlqkPoF2wCLVzzwmKLUB1OH9rtswMjQDj4pAo L5EYcKYn6nlIXe5AeDrxlQnCZrZc/D3iY8KvEkAq+JZD40yJMbyjNbRaeRE8iCo0NhlA fEiymZ1dz1ja9MXhbjAbo3D732jgeshb5tPl4AKBVoCsHzdPqBDAIgSXoJBCojEWsAcj aZUpjewasYKPGtnSh9WA2uFGQDEh24sGEC/l5mCsUASxVNZdxn5XnSW5Y/Z/0Rhg/Jgm pNYUq8jThIUCAI6L0ry2l68jT63yhMW1PntEDMo0AusPCybFshuf6jnKkaQ9mlmhaT1S 1DIA==
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; bh=19F8TjalytgDYersRnsunHYzseurAeLnjqlnaPjb9vo=; b=m1MqIj8pyqNJbAW5k9rLjh5t63ugC6tpcBmrtYAiqhYFHU5dD1d1BLguIbi3dt3uPE l0iITTMva4p/R7cPvbk84hIofNy+wi2oxvqi7mVnxn6dQxMjaJT3V6srHQy/O6Fv1ktG VN+NnAmmQkssRijHrVswNSZcykVpDpa3vC3oOPFPsAHXYDQG+6dulgAesdEsa8bc4yGI W+l2aNZPnIoofcOvgQLW4+TpeazLK/3TDJibf8ogCJ9zda7xwHckUz4p6kMAbe60a0yh 3iRiFNx43asoHbOwgW+yQuYG82tcrQhMkh7yG8ZPvTOwzWrc3WamljbUrOgVsznrTWlt Spgg==
X-Gm-Message-State: ALyK8tLz5uWT9tuQON63KhBv/yLa/1WVyOrGwhfVsaXRY9vgarS+WzKLI2XvWCR91ey0Kn7SgWYHx2A7XWS3qA==
X-Received: by 10.31.4.4 with SMTP id 4mr5277029vke.121.1468447113020; Wed, 13 Jul 2016 14:58:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Wed, 13 Jul 2016 14:58:32 -0700 (PDT)
In-Reply-To: <5786B8CE.3040507@seguesoft.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>
From: Andy Bierman 
Date: Wed, 13 Jul 2016 14:58:32 -0700
Message-ID: 
To: Xiang Li 
Content-Type: multipart/alternative; boundary=001a114298c88b1d3205378b7ca5
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jul 2016 21:58:38 -0000

--001a114298c88b1d3205378b7ca5
Content-Type: text/plain; charset=UTF-8

Hi,

The implementation has bugs.
The RFC is clear wrt/ operation=none vs merge or replace.



Andy


On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li  wrote:

> On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>
>
> On Jul 12, 2016, at 9:28 AM, Xiang Li < 
> xiangli@seguesoft.com> wrote:
>
> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
>
> The Opendaylight controller is constructing this particular set of
>  requests as part of a single transaction. The response of the
> server is to reject the configuration that the particular node (evpn
> container) does not exist.
>
> However, if the default-operation=none is removed or changed to replace,
> the server responds with an RPC OK.
>
> Is the server right in its interpretation of what RFC 6241 says? In
> particular, the way the server is interpreting this request is as follows
> from Section 7.2 of the RFC:
>
>          none:  The target datastore is unaffected by the configuration
>             in the  parameter, unless and until the incoming
>             configuration data uses the "operation" attribute to request
>             a different operation.  If the configuration in the 
>             parameter contains data for which there is not a
>             corresponding level in the target datastore, an 
>             is returned with an  value of data-missing.
>             Using "none" allows operations like "delete" to avoid
>             unintentionally creating the parent hierarchy of the element
>             to be deleted.
>
>
> and then this:
>
>       operation:  Elements in the  subtree MAY contain an
>          "operation" attribute, which belongs to the NETCONF namespace
>          defined in Section 3.1 .  The attribute identifies the point in
>          the configuration to perform the operation and MAY appear on
>          multiple elements throughout the  subtree.
>
>
>
> *1st request:*
>
> 
>   
>     
>       
>     
>     rollback-on-error
>     
>       
>         
>       
>     
>   
> 
> ##
>
> The container evpn in this case is a non-presence container and does not
> contain any mandatory leafs or default statements. The server therefore
> interprets that nothing has to be done here, as it is not required to
> create a empty container.
>
>
>
>
> I think the container node needs to be created when you are merging to
> create new nodes explicitly.
> RFC6020
> 7.5.  The container Statement
>    7.5.8.  NETCONF  Operations
>
>     When a NETCONF server processes an  request, the
>     elements of procedure for the container node are:
>
>       If the operation is "merge" or "replace", the node is created if
>       it does not exist.
>
>
> It makes no sense to me for the server to return ok but actually does not
> create that
> container node in this case.
>
>
> And that is the clarification I am seeking. Note, it is an empty
> non-presence container. Should the server create this empty container, and
> if so how would it be represented in the config tree? In this particular
> case, the request is followed by child nodes. What happens if no child
> nodes are created?
>
>
> My understanding is that it does not matter if it is a presence container
> or not in this case
> , nor if there are child nodes included  to be created.
>
>
>
>
> The server may delete an empty container node but only when you deleting
> stuff:
>
> If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container.
>
>
> For a delete it is clear. But the RFC is silent for a create (and the
> default operation of merge).
>
>
> I think RFC6020 7.5.8.  "NETCONF  Operations" (for container
> node)
> covers this :
>
> -    When a NETCONF server processes an  request, the
> -    elements of procedure for the container node are:
> -
> -      If the operation is "merge" or "replace", the node is created if
> -      it does not exist.
>
> -      If the operation is "create", the node is created if it does not
> -      exist.  If the node already exists, a "data-exists" error is
> -      returned.
>
>
>
> If a non-presence empty container can be deleted, why should it be created?
>
>
>
> It is because the client is sending an   to create this
> container explicitly.
> If a client wants to create *only* a container node, it can certainly do
> so without
> having to specify any child instance nodes. If the server returns "Ok" for
> such
> a request then it must mean it has indeed created the container node.
>
> I think it makes little sense for a server to return "Ok" but does not
> create
> the container node (thinking nothing needs to be done if there are no
> child nodes
> included in the same request). The "Ok" response must mean something, i.e.,
> the create/merge/replace operations has actually succeeded in creating the
> container node in question.
>
> -Xiang
>
>
> Thanks.
>
>
> *2nd request:*
>
> 
>   
>     
>       
>     
>     none
>     rollback-on-error
>     
>       
>         
>            xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
>             
>             
>           
>         
>       
>     
>   
> 
> ##
>
> In the second request, the default-operation=none again seems to imply
> that nothing needs to be done for creation of the evpn node. Therefore by
> the time the evpn-load-balancing request rolls around, the request is
> rejected as the parent container does not exist. As stated earlier, if the
> default-operation is removed (causing a default of merge) or replaced with
> a replace, the transaction succeeds.
>
> A second interpretation to this transaction is that the server should have
> created the evpn node as part of the first request, and that the none
> operation was implying that the node had already been created.
>
>
>
> If the server returns ok for the first , then it means it has
> successfully created the top two container nodes in the hierarchy:
>
>       
>         
>
> then the second request should have succeeded.
>
>
>
> -Xiang Li
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--001a114298c88b1d3205378b7ca5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The implementation has bugs.
<=
div>The RFC is clear wrt/ operation=3Dnone vs merge or replace.
<=
br>


Andy

=


On Wed, Jul 13, 2=
016 at 2:55 PM, Xiang Li <xiangli@seguesoft.com> wrote:<=
br>

 =20
   =20
 =20
  

    
On 7/12/2016 8:45 PM, Mahesh
      Jethanandani wrote:

    

    

     =20
      

      

        

          
On Jul 12, 2016, at 9:28 AM, Xiang Li <xiangli@seguesoft.com>
            wrote:

          

          

           =20
            

              
On 7/11/2016 3:47 PM, Mahesh
                Jethanandani wrote:

              

              

               =20
                
The Opendaylight controller is
                  constructing this particular set of
                  <edit-config> requests as part of a single
                  transaction. The response of the server is to reject
                  the configuration that the particular node (evpn
                  container) does not exist.=C2=A0

                


                

                
However, if the default-operation=3Dnone is
                  removed or changed to replace, the server responds
                  with an RPC OK.

                


                

                
Is the server right in its interpretation
                  of what RFC 6241 says? In particular, the way the
                  server is interpreting this request is as follows from
                  Section 7.2 of the RFC:

                


                

                

                  
         none:  The t=
arget datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to =
request
            a different operation.  If the configuration in the <=
config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error&g=
t;
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete"=
; to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


                

                


                

                
and then this:

                


                

                

                  
      operation:  Elements in the <config&=
gt; subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF name=
space
         defined in Section 3.1.  The attrib=
ute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


                

                


                

                


                

                

                  
=
1st=C2=A0request:

                  
=C2=A0

                  
<rpc
                      xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0=
"
                      message-id=3D"m-23">

                  
=C2=A0 <edit-config>=


                  
=C2=A0=C2=A0=C2=A0 <target>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <candidate/&g=
t;

                  
=C2=A0=C2=A0=C2=A0 </target>

                  
=C2=A0=C2=A0=C2=A0
                      <error-option>rollback-on-error</error-optio=
n>

                  
=C2=A0=C2=A0=C2=A0 <config>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn xmlns=
=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"=
;>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
evpn-tables/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn>=


                  
=C2=A0=C2=A0=C2=A0 </config>

                  
=C2=A0 </edit-config>

                  
</rpc>

                  
##

                  
=C2=A0

                  
The
                    container evpn in this case is a non-presence
                    container and does not contain any mandatory leafs
                    or default statements. The server therefore
                    interprets that nothing has to be done here, as it
                    is not required to create a empty container.

                  
=C2=A0

                

              

              

              

              I think the container node needs to be created when you
              are merging to create new nodes explicitly.

              RFC6020 

              7.5.=C2=A0 The container Statement

              =C2=A0=C2=A0 7.5.8.=C2=A0 NETCONF <edit-config> Operati=
ons

              
    Wh=
en a NETCONF server processes an <edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the nod=
e is created if
      it does not exist.



              It makes no sense to me for the server to return ok but
              actually does not create that

              container node in this case.

            

          

        

        


        

        And that is the clarification I am seeking. Note, it is an empty
        non-presence container. Should the server create this empty
        container, and if so how would it be represented in the config
        tree? In this particular case, the request is followed by child
        nodes. What happens if no child nodes are created?

      


      

    

    

    My understanding is that it does not matter if it is a presence
    container or not in this case

    , nor if there are child nodes included=C2=A0 to be created.

    

    

    

      

        

          

            
 

              

              The server may delete an empty container node but only
              when you deleting stuff:

              

              
If a container does not have a "presence" statement and the =
last
   child node is deleted, the NETCONF server MAY delete the container.


            

          

        

        


        

        For a delete it is clear. But the RFC is silent for a create
        (and the default operation of merge).

    

    

    I think RFC6020 7.5.8.=C2=A0 "NETCONF <edit-config> Operatio=
ns"
    (for container node)

    covers this :
    
-    When a NETC=
ONF server processes an <edit-config> request, the
-    elements of procedure for the container node are:
-
-      If the operation is "merge" or "replace", the no=
de is created if
-      it does not exist.
    =20
-      If the operation is "create", the node is created if it do=
es not
-      exist.  If the node already exists, a "data-exists" error =
is
-      returned.


    

    

    

      
 If a non-presence empty container can be deleted, why should
        it be created?

    

    

    

    It is because the client is sending an <edit-config>=C2=A0 to
    create this container explicitly.

    If a client wants to create *only* a container node, it can
    certainly do so without 

    having to specify any child instance nodes. If the server returns
    "Ok" for such

    a request then it must mean it has indeed created the container
    node.

    

    I think it makes little sense for a server to return "Ok" but=
 does
    not create 

    the container node (thinking nothing needs to be done if there are
    no child nodes

    included in the same request). The "Ok" response must mean
    something, i.e.,

    the create/merge/replace operations has actually succeeded in
    creating the 

    container node in question.

    

    -Xiang

    

    

      


      

      
Thanks.

      


        

          

            

              

              

              

                

                  
=
2nd=C2=A0request:

                  
=C2=A0

                  
<rpc
                      xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0=
"
                      message-id=3D"m-24">

                  
=C2=A0 <edit-config>=


                  
=C2=A0=C2=A0=C2=A0 <target>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <candidate/&g=
t;

                  
=C2=A0=C2=A0=C2=A0 </target>

                  
=C2=A0=C2=A0=C2=A0
                      <default-operation>none</default-operation&g=
t;

                  
=C2=A0=C2=A0=C2=A0
                      <error-option>rollback-on-error</error-optio=
n>

                  
=C2=A0=C2=A0=C2=A0 <config>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn xmlns=
=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"=
;>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
evpn-tables>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 <evpn-load-balancing
                      xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1=
.0"
                      a:operation=3D"replace">

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <enable/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <evpn-flow-label/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </evpn-load-balancing>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/evpn-tables>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn>=


                  
=C2=A0=C2=A0=C2=A0 </config>

                  
=C2=A0 </edit-config>

                  
</rpc>

                  
##

                  


                    
In the second request, the
                      default-operation=3Dnone again seems to imply that
                      nothing needs to be done for creation of the evpn
                      node. Therefore by the time the
                      evpn-load-balancing request rolls around, the
                      request is rejected as the parent container does
                      not exist. As stated earlier, if the
                      default-operation is removed (causing a default of
                      merge) or replaced with a replace, the transaction
                      succeeds.

                    


                    

                    
A second interpretation to this
                      transaction is that the server should have created
                      the evpn node as part of the first request, and
                      that the none operation was implying that the node
                      had already been created.

                    


                    

                  

                

              

              

              

              If the server returns ok for the first
              <edit-config>, then it means it has successfully
              created the top two container nodes in the hierarchy:

              

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  <evpn >

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                <evpn-tables>

                

                then the second request should have succeeded.

          

        

        

          

            
 

              

              -Xiang Li

              
 

            

          

        

      

      

      

        
Mahesh Jethanandani

        
        


        

        

      

      

    

  



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a114298c88b1d3205378b7ca5--


From nobody Thu Jul 14 09:10:14 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030F12B03D for ; Thu, 14 Jul 2016 09:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFAwm7jcednS for ; Thu, 14 Jul 2016 09:10:10 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD18312D0BC for ; Thu, 14 Jul 2016 09:10:09 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id j126so63711632vkg.3 for ; Thu, 14 Jul 2016 09:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eytj0rZ8UQ6AYo1D9MANJVFtpb56LYN3FXm0V8aMbvQ=; b=CFiObI4X7VjfwPb5/vRqu3Jo0+9LwKjM31uGvf0Hwzf0xuDo0kf4iSlIcDpDFQBzQr zLVcML3eLTbVnhzRZFMfgpvfKbsixPTa1yyIVDyTsK5OqVhSVBMv9XAbifMGmDSZOQQh txP14zGiZbZzx6wbSUfxoCCC3G/UQkLYgMI2G4AiaRy+kU2wnYfO3sDsoJrCsG2gVaAI yVhp1/t+dEiTnMCFNTA1fqb6Q7iuewgkFNWToN4chN+PGDS0/jLyRX7JnKtnzX8uqbaK zZvEkaDznQD1d/mnq7ZE14qrJhpU2GVtxWrAxuISyLaCI/YmuohcyQwsV4pP1bgdZM/H jOYQ==
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; bh=Eytj0rZ8UQ6AYo1D9MANJVFtpb56LYN3FXm0V8aMbvQ=; b=jF79YVJc3Rdf3+X8eQT9K0Zsmn1QP5eONkEDqc/dbbQeD7wVy0ccNOIhJja0LsRFVa 39piu15fu+9ledvaTbFlMLNM0UnMLFT7SH4r5fd1LSK/kKptH0JsWNTIGhJZh/MBbcn3 Oj01KMwsaYG54j4huRIQLz4UIsBgSmAZr92ElDcfbN1R+6E48QRyULMu4OnloLy1mhop 5egrf1mk0WFI/ZdVO4ZuQBFdKjJKJmTxWBJ4/KAG0I+pAEMTrZl6h/T9u6ABCfpgbgTX o+70rF2LqzLcwSYqJwKanWs6jwJ3eJdebHU8hqLJta88SK3CbAC7z3QUfSFoWlKqGtZK iXbw==
X-Gm-Message-State: ALyK8tK8Ncxew3KF990zoXWPzKbssyiuuSZ09LGwx5bZ4rvpOykLE7bUDmcGvmGbJNr0B8q6ShtMTgP++Kjt+Q==
X-Received: by 10.176.67.4 with SMTP id k4mr7522204uak.47.1468512608796; Thu, 14 Jul 2016 09:10:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 09:10:08 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com> 
From: Andy Bierman 
Date: Thu, 14 Jul 2016 09:10:08 -0700
Message-ID: 
To: Xiang Li 
Content-Type: multipart/alternative; boundary=94eb2c09507a6555ee05379abca8
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 16:10:12 -0000

--94eb2c09507a6555ee05379abca8
Content-Type: text/plain; charset=UTF-8

Hi,

Mahesh asked me to be more specific.
If the server is returning  for edit 1 but the candidate datastore
is still empty after edit 1 then this is a server bug.

Andy

On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman  wrote:

> Hi,
>
> The implementation has bugs.
> The RFC is clear wrt/ operation=none vs merge or replace.
>
>
>
> Andy
>
>
> On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li  wrote:
>
>> On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>>
>>
>> On Jul 12, 2016, at 9:28 AM, Xiang Li < 
>> xiangli@seguesoft.com> wrote:
>>
>> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
>>
>> The Opendaylight controller is constructing this particular set of
>>  requests as part of a single transaction. The response of the
>> server is to reject the configuration that the particular node (evpn
>> container) does not exist.
>>
>> However, if the default-operation=none is removed or changed to replace,
>> the server responds with an RPC OK.
>>
>> Is the server right in its interpretation of what RFC 6241 says? In
>> particular, the way the server is interpreting this request is as follows
>> from Section 7.2 of the RFC:
>>
>>          none:  The target datastore is unaffected by the configuration
>>             in the  parameter, unless and until the incoming
>>             configuration data uses the "operation" attribute to request
>>             a different operation.  If the configuration in the 
>>             parameter contains data for which there is not a
>>             corresponding level in the target datastore, an 
>>             is returned with an  value of data-missing.
>>             Using "none" allows operations like "delete" to avoid
>>             unintentionally creating the parent hierarchy of the element
>>             to be deleted.
>>
>>
>> and then this:
>>
>>       operation:  Elements in the  subtree MAY contain an
>>          "operation" attribute, which belongs to the NETCONF namespace
>>          defined in Section 3.1 .  The attribute identifies the point in
>>          the configuration to perform the operation and MAY appear on
>>          multiple elements throughout the  subtree.
>>
>>
>>
>> *1st request:*
>>
>> 
>>   
>>     
>>       
>>     
>>     rollback-on-error
>>     
>>       
>>         
>>       
>>     
>>   
>> 
>> ##
>>
>> The container evpn in this case is a non-presence container and does not
>> contain any mandatory leafs or default statements. The server therefore
>> interprets that nothing has to be done here, as it is not required to
>> create a empty container.
>>
>>
>>
>>
>> I think the container node needs to be created when you are merging to
>> create new nodes explicitly.
>> RFC6020
>> 7.5.  The container Statement
>>    7.5.8.  NETCONF  Operations
>>
>>     When a NETCONF server processes an  request, the
>>     elements of procedure for the container node are:
>>
>>       If the operation is "merge" or "replace", the node is created if
>>       it does not exist.
>>
>>
>> It makes no sense to me for the server to return ok but actually does not
>> create that
>> container node in this case.
>>
>>
>> And that is the clarification I am seeking. Note, it is an empty
>> non-presence container. Should the server create this empty container, and
>> if so how would it be represented in the config tree? In this particular
>> case, the request is followed by child nodes. What happens if no child
>> nodes are created?
>>
>>
>> My understanding is that it does not matter if it is a presence container
>> or not in this case
>> , nor if there are child nodes included  to be created.
>>
>>
>>
>>
>> The server may delete an empty container node but only when you deleting
>> stuff:
>>
>> If a container does not have a "presence" statement and the last
>>    child node is deleted, the NETCONF server MAY delete the container.
>>
>>
>> For a delete it is clear. But the RFC is silent for a create (and the
>> default operation of merge).
>>
>>
>> I think RFC6020 7.5.8.  "NETCONF  Operations" (for container
>> node)
>> covers this :
>>
>> -    When a NETCONF server processes an  request, the
>> -    elements of procedure for the container node are:
>> -
>> -      If the operation is "merge" or "replace", the node is created if
>> -      it does not exist.
>>
>> -      If the operation is "create", the node is created if it does not
>> -      exist.  If the node already exists, a "data-exists" error is
>> -      returned.
>>
>>
>>
>> If a non-presence empty container can be deleted, why should it be
>> created?
>>
>>
>>
>> It is because the client is sending an   to create this
>> container explicitly.
>> If a client wants to create *only* a container node, it can certainly do
>> so without
>> having to specify any child instance nodes. If the server returns "Ok"
>> for such
>> a request then it must mean it has indeed created the container node.
>>
>> I think it makes little sense for a server to return "Ok" but does not
>> create
>> the container node (thinking nothing needs to be done if there are no
>> child nodes
>> included in the same request). The "Ok" response must mean something,
>> i.e.,
>> the create/merge/replace operations has actually succeeded in creating
>> the
>> container node in question.
>>
>> -Xiang
>>
>>
>> Thanks.
>>
>>
>> *2nd request:*
>>
>> 
>>   
>>     
>>       
>>     
>>     none
>>     rollback-on-error
>>     
>>       
>>         
>>           > xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
>>             
>>             
>>           
>>         
>>       
>>     
>>   
>> 
>> ##
>>
>> In the second request, the default-operation=none again seems to imply
>> that nothing needs to be done for creation of the evpn node. Therefore by
>> the time the evpn-load-balancing request rolls around, the request is
>> rejected as the parent container does not exist. As stated earlier, if the
>> default-operation is removed (causing a default of merge) or replaced with
>> a replace, the transaction succeeds.
>>
>> A second interpretation to this transaction is that the server should
>> have created the evpn node as part of the first request, and that the none
>> operation was implying that the node had already been created.
>>
>>
>>
>> If the server returns ok for the first , then it means it
>> has successfully created the top two container nodes in the hierarchy:
>>
>>       
>>         
>>
>> then the second request should have succeeded.
>>
>>
>>
>> -Xiang Li
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>

--94eb2c09507a6555ee05379abca8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Mahesh asked me to be more specific=
.
If the server is returning <ok/> for edit 1 but the candi=
date datastore
is still empty after edit 1 then this is a server =
bug.

Andy

On Wed, Jul 13, 2016 at 2:58 P=
M, Andy Bierman <andy@yumaworks.com> wrote:
Hi,

The implementati=
on has bugs.
The RFC is clear wrt/ operation=3Dnone vs merge or r=
eplace.



Andy


On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li <xiangli@seguesoft.com> wrote:

 =20
   =20
 =20
  

    
On 7/12/2016 8:45 PM, Mahesh
      Jethanandani wrote:

    

    

     =20
      

      

        

          
          

          

           =20
            

              
On 7/11/2016 3:47 PM, Mahesh
                Jethanandani wrote:

              

              

               =20
                
The Opendaylight controller is
                  constructing this particular set of
                  <edit-config> requests as part of a single
                  transaction. The response of the server is to reject
                  the configuration that the particular node (evpn
                  container) does not exist.=C2=A0

                


                

                
However, if the default-operation=3Dnone is
                  removed or changed to replace, the server responds
                  with an RPC OK.

                


                

                
Is the server right in its interpretation
                  of what RFC 6241 says? In particular, the way the
                  server is interpreting this request is as follows from
                  Section 7.2 of the RFC:

                


                

                

                  
         none:  The t=
arget datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to =
request
            a different operation.  If the configuration in the <=
config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error&g=
t;
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete"=
; to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


                

                


                

                
and then this:

                


                

                

                  
      operation:  Elements in the <config&=
gt; subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF name=
space
         defined in Section 3.1.  The attrib=
ute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


                

                


                

                


                

                

                  
=
1st=C2=A0request:

                  
=C2=A0

                  
<rpc
                      xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0=
"
                      message-id=3D"m-23">

                  
=C2=A0 <edit-config>=


                  
=C2=A0=C2=A0=C2=A0 <target>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <candidate/&g=
t;

                  
=C2=A0=C2=A0=C2=A0 </target>

                  
=C2=A0=C2=A0=C2=A0
                      <error-option>rollback-on-error</error-optio=
n>

                  
=C2=A0=C2=A0=C2=A0 <config>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn xmlns=
=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"=
;>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
evpn-tables/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn>=


                  
=C2=A0=C2=A0=C2=A0 </config>

                  
=C2=A0 </edit-config>

                  
</rpc>

                  
##

                  
=C2=A0

                  
The
                    container evpn in this case is a non-presence
                    container and does not contain any mandatory leafs
                    or default statements. The server therefore
                    interprets that nothing has to be done here, as it
                    is not required to create a empty container.

                  
=C2=A0

                

              

              

              

              I think the container node needs to be created when you
              are merging to create new nodes explicitly.

              RFC6020 

              7.5.=C2=A0 The container Statement

              =C2=A0=C2=A0 7.5.8.=C2=A0 NETCONF <edit-config> Operati=
ons

              
    Wh=
en a NETCONF server processes an <edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the nod=
e is created if
      it does not exist.



              It makes no sense to me for the server to return ok but
              actually does not create that

              container node in this case.

            

          

        

        


        

        And that is the clarification I am seeking. Note, it is an empty
        non-presence container. Should the server create this empty
        container, and if so how would it be represented in the config
        tree? In this particular case, the request is followed by child
        nodes. What happens if no child nodes are created?

      


      

    

    

    My understanding is that it does not matter if it is a presence
    container or not in this case

    , nor if there are child nodes included=C2=A0 to be created.

    

    

    

      

        

          

            
 

              

              The server may delete an empty container node but only
              when you deleting stuff:

              

              
If a container does not have a "presence" statement and the =
last
   child node is deleted, the NETCONF server MAY delete the container.


            

          

        

        


        

        For a delete it is clear. But the RFC is silent for a create
        (and the default operation of merge).

    

    

    I think RFC6020 7.5.8.=C2=A0 "NETCONF <edit-config> Operatio=
ns"
    (for container node)

    covers this :
    
-    When a NETC=
ONF server processes an <edit-config> request, the
-    elements of procedure for the container node are:
-
-      If the operation is "merge" or "replace", the no=
de is created if
-      it does not exist.
    =20
-      If the operation is "create", the node is created if it do=
es not
-      exist.  If the node already exists, a "data-exists" error =
is
-      returned.


    

    

    

      
 If a non-presence empty container can be deleted, why should
        it be created?

    

    

    

    It is because the client is sending an <edit-config>=C2=A0 to
    create this container explicitly.

    If a client wants to create *only* a container node, it can
    certainly do so without 

    having to specify any child instance nodes. If the server returns
    "Ok" for such

    a request then it must mean it has indeed created the container
    node.

    

    I think it makes little sense for a server to return "Ok" but=
 does
    not create 

    the container node (thinking nothing needs to be done if there are
    no child nodes

    included in the same request). The "Ok" response must mean
    something, i.e.,

    the create/merge/replace operations has actually succeeded in
    creating the 

    container node in question.

    

    -Xiang

    

    

      


      

      
Thanks.

      


        

          

            

              

              

              

                

                  
=
2nd=C2=A0request:

                  
=C2=A0

                  
<rpc
                      xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0=
"
                      message-id=3D"m-24">

                  
=C2=A0 <edit-config>=


                  
=C2=A0=C2=A0=C2=A0 <target>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <candidate/&g=
t;

                  
=C2=A0=C2=A0=C2=A0 </target>

                  
=C2=A0=C2=A0=C2=A0
                      <default-operation>none</default-operation&g=
t;

                  
=C2=A0=C2=A0=C2=A0
                      <error-option>rollback-on-error</error-optio=
n>

                  
=C2=A0=C2=A0=C2=A0 <config>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn xmlns=
=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"=
;>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
evpn-tables>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 <evpn-load-balancing
                      xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1=
.0"
                      a:operation=3D"replace">

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <enable/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <evpn-flow-label/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </evpn-load-balancing>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/evpn-tables>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn>=


                  
=C2=A0=C2=A0=C2=A0 </config>

                  
=C2=A0 </edit-config>

                  
</rpc>

                  
##

                  


                    
In the second request, the
                      default-operation=3Dnone again seems to imply that
                      nothing needs to be done for creation of the evpn
                      node. Therefore by the time the
                      evpn-load-balancing request rolls around, the
                      request is rejected as the parent container does
                      not exist. As stated earlier, if the
                      default-operation is removed (causing a default of
                      merge) or replaced with a replace, the transaction
                      succeeds.

                    


                    

                    
A second interpretation to this
                      transaction is that the server should have created
                      the evpn node as part of the first request, and
                      that the none operation was implying that the node
                      had already been created.

                    


                    

                  

                

              

              

              

              If the server returns ok for the first
              <edit-config>, then it means it has successfully
              created the top two container nodes in the hierarchy:

              

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  <evpn >

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                <evpn-tables>

                

                then the second request should have succeeded.

          

        

        

          

            
 

              

              -Xiang Li

              
 

            

          

        

      

      

      

        
Mahesh Jethanandani

        
        


        

        

      

      

    

  



_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf








--94eb2c09507a6555ee05379abca8--


From nobody Thu Jul 14 09:16:03 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E5F12D128 for ; Thu, 14 Jul 2016 09:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptzNg6NJDvBl for ; Thu, 14 Jul 2016 09:15:59 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2845F12D14B for ; Thu, 14 Jul 2016 09:15:59 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id o63so118505203vkg.1 for ; Thu, 14 Jul 2016 09:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nc9PpkWUxxurlDKgpeztvQYvdNDbv01+xx72JiqmCvg=; b=0bjSOTh/BRac20uCKr74fG5LhBU+fyJJ1CgwLWa4moh8EJEzy+Lzge4pBTjKbPNpU9 RK1gH43XHPT318WKuGnafJgNQj/3ru0WJ68lO7tB/fNZoN70/197CwuTzJHKQHU1/lEm lynefTWGkPN4fqjJs/KFYXg+MPjCi0OvvucloLNoavbN9mH/ef8cBRQHY2/rW8JT7AqZ yVxZcDpFSgAFsMWOTYPRLzqqHsPVOcFkOrR15zD5hG30JmpbY4psKzHz6kjEldiyXy3B /g1kPg42ADEcTWIEFe0v1Saz2fdmgFMp3KYzBQenXUo0jIvHgk8JJuocgT2ImM8FxwLD Yfpg==
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; bh=nc9PpkWUxxurlDKgpeztvQYvdNDbv01+xx72JiqmCvg=; b=aYdyFJbS5AVuP/TQ1AZ7ZETC2ylOYC4V9tdxAk5NG232iPL5MKKY7wFKHP2haW0ufU l+JQMx92XTXTmc7FfkUo1kZK4GLZSAM9Iiy7iW2ACRhP7r8WXze+4qHtwKG23osGy1do aCmekiKrOHQBV6eAiQyU1z/9LHj8rGVVElt/jzl0QqrvH4c0SJcPbSVx9lYw6Xwkja4g 9s+YilqcBnBrcvbiRz/iXNQUc1du9qbobdp54AS5btqKvzCC2SeBRErA97r8vaZSc08u ylvFoCaIYr8+nljzGisfeFg+qhQa4r86SQRT0yLatgz66a2riMe5qM8tNYhcTmrVJBLd IACA==
X-Gm-Message-State: ALyK8tKtkMOXdX577F78XtMB0CBWxYFiP/siG6bWifYwLs4RT2Igpds2xX5mNmminMaxD749q5PLApsocdtddg==
X-Received: by 10.31.231.3 with SMTP id e3mr7595625vkh.13.1468512958038; Thu, 14 Jul 2016 09:15:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 09:15:57 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>  
From: Andy Bierman 
Date: Thu, 14 Jul 2016 09:15:57 -0700
Message-ID: 
To: Xiang Li 
Content-Type: multipart/alternative; boundary=94eb2c095ca436629905379ad158
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 16:16:02 -0000

--94eb2c095ca436629905379ad158
Content-Type: text/plain; charset=UTF-8

Hi,

I can see the confusion because of the sloppy text in RFC 6241.
NP containers have always been a problem.  The NETMOD WG did a poor job
of defining them in an interoperable way.

IMO the server should not delete NP containers for exactly the cases you
point out.
The server does not know the client's intentions so why is it deleting
nodes?
Also, YANG 1.1 XPath rules treat NP containers as if they are always
present.
(So the text about MAY delete NP containers is even more confusing).


Andy


On Thu, Jul 14, 2016 at 9:10 AM, Andy Bierman  wrote:

> Hi,
>
> Mahesh asked me to be more specific.
> If the server is returning  for edit 1 but the candidate datastore
> is still empty after edit 1 then this is a server bug.
>
> Andy
>
> On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman  wrote:
>
>> Hi,
>>
>> The implementation has bugs.
>> The RFC is clear wrt/ operation=none vs merge or replace.
>>
>>
>>
>> Andy
>>
>>
>> On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li  wrote:
>>
>>> On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>>>
>>>
>>> On Jul 12, 2016, at 9:28 AM, Xiang Li < 
>>> xiangli@seguesoft.com> wrote:
>>>
>>> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
>>>
>>> The Opendaylight controller is constructing this particular set of
>>>  requests as part of a single transaction. The response of the
>>> server is to reject the configuration that the particular node (evpn
>>> container) does not exist.
>>>
>>> However, if the default-operation=none is removed or changed to replace,
>>> the server responds with an RPC OK.
>>>
>>> Is the server right in its interpretation of what RFC 6241 says? In
>>> particular, the way the server is interpreting this request is as follows
>>> from Section 7.2 of the RFC:
>>>
>>>          none:  The target datastore is unaffected by the configuration
>>>             in the  parameter, unless and until the incoming
>>>             configuration data uses the "operation" attribute to request
>>>             a different operation.  If the configuration in the 
>>>             parameter contains data for which there is not a
>>>             corresponding level in the target datastore, an 
>>>             is returned with an  value of data-missing.
>>>             Using "none" allows operations like "delete" to avoid
>>>             unintentionally creating the parent hierarchy of the element
>>>             to be deleted.
>>>
>>>
>>> and then this:
>>>
>>>       operation:  Elements in the  subtree MAY contain an
>>>          "operation" attribute, which belongs to the NETCONF namespace
>>>          defined in Section 3.1 .  The attribute identifies the point in
>>>          the configuration to perform the operation and MAY appear on
>>>          multiple elements throughout the  subtree.
>>>
>>>
>>>
>>> *1st request:*
>>>
>>> 
>>>   
>>>     
>>>       
>>>     
>>>     rollback-on-error
>>>     
>>>       
>>>         
>>>       
>>>     
>>>   
>>> 
>>> ##
>>>
>>> The container evpn in this case is a non-presence container and does not
>>> contain any mandatory leafs or default statements. The server therefore
>>> interprets that nothing has to be done here, as it is not required to
>>> create a empty container.
>>>
>>>
>>>
>>>
>>> I think the container node needs to be created when you are merging to
>>> create new nodes explicitly.
>>> RFC6020
>>> 7.5.  The container Statement
>>>    7.5.8.  NETCONF  Operations
>>>
>>>     When a NETCONF server processes an  request, the
>>>     elements of procedure for the container node are:
>>>
>>>       If the operation is "merge" or "replace", the node is created if
>>>       it does not exist.
>>>
>>>
>>> It makes no sense to me for the server to return ok but actually does
>>> not create that
>>> container node in this case.
>>>
>>>
>>> And that is the clarification I am seeking. Note, it is an empty
>>> non-presence container. Should the server create this empty container, and
>>> if so how would it be represented in the config tree? In this particular
>>> case, the request is followed by child nodes. What happens if no child
>>> nodes are created?
>>>
>>>
>>> My understanding is that it does not matter if it is a presence
>>> container or not in this case
>>> , nor if there are child nodes included  to be created.
>>>
>>>
>>>
>>>
>>> The server may delete an empty container node but only when you deleting
>>> stuff:
>>>
>>> If a container does not have a "presence" statement and the last
>>>    child node is deleted, the NETCONF server MAY delete the container.
>>>
>>>
>>> For a delete it is clear. But the RFC is silent for a create (and the
>>> default operation of merge).
>>>
>>>
>>> I think RFC6020 7.5.8.  "NETCONF  Operations" (for
>>> container node)
>>> covers this :
>>>
>>> -    When a NETCONF server processes an  request, the
>>> -    elements of procedure for the container node are:
>>> -
>>> -      If the operation is "merge" or "replace", the node is created if
>>> -      it does not exist.
>>>
>>> -      If the operation is "create", the node is created if it does not
>>> -      exist.  If the node already exists, a "data-exists" error is
>>> -      returned.
>>>
>>>
>>>
>>> If a non-presence empty container can be deleted, why should it be
>>> created?
>>>
>>>
>>>
>>> It is because the client is sending an   to create this
>>> container explicitly.
>>> If a client wants to create *only* a container node, it can certainly do
>>> so without
>>> having to specify any child instance nodes. If the server returns "Ok"
>>> for such
>>> a request then it must mean it has indeed created the container node.
>>>
>>> I think it makes little sense for a server to return "Ok" but does not
>>> create
>>> the container node (thinking nothing needs to be done if there are no
>>> child nodes
>>> included in the same request). The "Ok" response must mean something,
>>> i.e.,
>>> the create/merge/replace operations has actually succeeded in creating
>>> the
>>> container node in question.
>>>
>>> -Xiang
>>>
>>>
>>> Thanks.
>>>
>>>
>>> *2nd request:*
>>>
>>> 
>>>   
>>>     
>>>       
>>>     
>>>     none
>>>     rollback-on-error
>>>     
>>>       
>>>         
>>>           >> xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
>>>             
>>>             
>>>           
>>>         
>>>       
>>>     
>>>   
>>> 
>>> ##
>>>
>>> In the second request, the default-operation=none again seems to imply
>>> that nothing needs to be done for creation of the evpn node. Therefore by
>>> the time the evpn-load-balancing request rolls around, the request is
>>> rejected as the parent container does not exist. As stated earlier, if the
>>> default-operation is removed (causing a default of merge) or replaced with
>>> a replace, the transaction succeeds.
>>>
>>> A second interpretation to this transaction is that the server should
>>> have created the evpn node as part of the first request, and that the none
>>> operation was implying that the node had already been created.
>>>
>>>
>>>
>>> If the server returns ok for the first , then it means it
>>> has successfully created the top two container nodes in the hierarchy:
>>>
>>>       
>>>         
>>>
>>> then the second request should have succeeded.
>>>
>>>
>>>
>>> -Xiang Li
>>>
>>>
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>>
>>
>

--94eb2c095ca436629905379ad158
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I can see the confusion because of =
the sloppy text in RFC 6241.
NP containers have always been a pro=
blem.=C2=A0 The NETMOD WG did a poor job
of defining them in an i=
nteroperable way.

IMO the server should not delete=
 NP containers for exactly the cases you point out.
The server do=
es not know the client's intentions so why is it deleting nodes?
<=
div>Also, YANG 1.1 XPath rules treat NP containers as if they are always pr=
esent.
(So the text about MAY delete NP containers is even more c=
onfusing).


Andy


On Thu, Ju=
l 14, 2016 at 9:10 AM, Andy Bierman <andy@yumaworks.com> wr=
ote:
Hi,

<=
div>Mahesh asked me to be more specific.
If the server is returni=
ng <ok/> for edit 1 but the candidate datastore
is still em=
pty after edit 1 then this is a server bug.

Andy

On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman &=
lt;andy@yumaworks.c=
om> wrote:
Hi,

The implementation has bugs.
The RFC is c=
lear wrt/ operation=3Dnone vs merge or replace.


Andy


On Wed, Jul 13, 2016 at 2:55 PM, =
Xiang Li <xiangli@seguesoft.com> wrote:

 =20
   =20
 =20
  

    
On 7/12/2016 8:45 PM, Mahesh
      Jethanandani wrote:

    

    

     =20
      

      

        

          
On Jul 12, 2016, at 9:28 AM, Xiang Li <xiangli@seguesoft.com>
            wrote:

          

          

           =20
            

              
On 7/11/2016 3:47 PM, Mahesh
                Jethanandani wrote:

              

              

               =20
                
The Opendaylight controller is
                  constructing this particular set of
                  <edit-config> requests as part of a single
                  transaction. The response of the server is to reject
                  the configuration that the particular node (evpn
                  container) does not exist.=C2=A0

                


                

                
However, if the default-operation=3Dnone is
                  removed or changed to replace, the server responds
                  with an RPC OK.

                


                

                
Is the server right in its interpretation
                  of what RFC 6241 says? In particular, the way the
                  server is interpreting this request is as follows from
                  Section 7.2 of the RFC:

                


                

                

                  
         none:  The t=
arget datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to =
request
            a different operation.  If the configuration in the <=
config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error&g=
t;
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete"=
; to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


                

                


                

                
and then this:

                


                

                

                  
      operation:  Elements in the <config&=
gt; subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF name=
space
         defined in Section 3.1.  The attrib=
ute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


                

                


                

                


                

                

                  
=
1st=C2=A0request:

                  
=C2=A0

                  
<rpc
                      xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0=
"
                      message-id=3D"m-23">

                  
=C2=A0 <edit-config>=


                  
=C2=A0=C2=A0=C2=A0 <target>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <candidate/&g=
t;

                  
=C2=A0=C2=A0=C2=A0 </target>

                  
=C2=A0=C2=A0=C2=A0
                      <error-option>rollback-on-error</error-optio=
n>

                  
=C2=A0=C2=A0=C2=A0 <config>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn xmlns=
=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"=
;>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
evpn-tables/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn>=


                  
=C2=A0=C2=A0=C2=A0 </config>

                  
=C2=A0 </edit-config>

                  
</rpc>

                  
##

                  
=C2=A0

                  
The
                    container evpn in this case is a non-presence
                    container and does not contain any mandatory leafs
                    or default statements. The server therefore
                    interprets that nothing has to be done here, as it
                    is not required to create a empty container.

                  
=C2=A0

                

              

              

              

              I think the container node needs to be created when you
              are merging to create new nodes explicitly.

              RFC6020 

              7.5.=C2=A0 The container Statement

              =C2=A0=C2=A0 7.5.8.=C2=A0 NETCONF <edit-config> Operati=
ons

              
    Wh=
en a NETCONF server processes an <edit-config> request, the
    elements of procedure for the container node are:

      If the operation is "merge" or "replace", the nod=
e is created if
      it does not exist.



              It makes no sense to me for the server to return ok but
              actually does not create that

              container node in this case.

            

          

        

        


        

        And that is the clarification I am seeking. Note, it is an empty
        non-presence container. Should the server create this empty
        container, and if so how would it be represented in the config
        tree? In this particular case, the request is followed by child
        nodes. What happens if no child nodes are created?

      


      

    

    

    My understanding is that it does not matter if it is a presence
    container or not in this case

    , nor if there are child nodes included=C2=A0 to be created.

    

    

    

      

        

          

            
 

              

              The server may delete an empty container node but only
              when you deleting stuff:

              

              
If a container does not have a "presence" statement and the =
last
   child node is deleted, the NETCONF server MAY delete the container.


            

          

        

        


        

        For a delete it is clear. But the RFC is silent for a create
        (and the default operation of merge).

    

    

    I think RFC6020 7.5.8.=C2=A0 "NETCONF <edit-config> Operatio=
ns"
    (for container node)

    covers this :
    
-    When a NETC=
ONF server processes an <edit-config> request, the
-    elements of procedure for the container node are:
-
-      If the operation is "merge" or "replace", the no=
de is created if
-      it does not exist.
    =20
-      If the operation is "create", the node is created if it do=
es not
-      exist.  If the node already exists, a "data-exists" error =
is
-      returned.


    

    

    

      
 If a non-presence empty container can be deleted, why should
        it be created?

    

    

    

    It is because the client is sending an <edit-config>=C2=A0 to
    create this container explicitly.

    If a client wants to create *only* a container node, it can
    certainly do so without 

    having to specify any child instance nodes. If the server returns
    "Ok" for such

    a request then it must mean it has indeed created the container
    node.

    

    I think it makes little sense for a server to return "Ok" but=
 does
    not create 

    the container node (thinking nothing needs to be done if there are
    no child nodes

    included in the same request). The "Ok" response must mean
    something, i.e.,

    the create/merge/replace operations has actually succeeded in
    creating the 

    container node in question.

    

    -Xiang

    

    

      


      

      
Thanks.

      


        

          

            

              

              

              

                

                  
=
2nd=C2=A0request:

                  
=C2=A0

                  
<rpc
                      xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0=
"
                      message-id=3D"m-24">

                  
=C2=A0 <edit-config>=


                  
=C2=A0=C2=A0=C2=A0 <target>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <candidate/&g=
t;

                  
=C2=A0=C2=A0=C2=A0 </target>

                  
=C2=A0=C2=A0=C2=A0
                      <default-operation>none</default-operation&g=
t;

                  
=C2=A0=C2=A0=C2=A0
                      <error-option>rollback-on-error</error-optio=
n>

                  
=C2=A0=C2=A0=C2=A0 <config>=


                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn xmlns=
=3D"http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg"=
;>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
evpn-tables>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 <evpn-load-balancing
                      xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1=
.0"
                      a:operation=3D"replace">

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <enable/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <evpn-flow-label/>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 </evpn-load-balancing>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/evpn-tables>

                  
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn>=


                  
=C2=A0=C2=A0=C2=A0 </config>

                  
=C2=A0 </edit-config>

                  
</rpc>

                  
##

                  


                    
In the second request, the
                      default-operation=3Dnone again seems to imply that
                      nothing needs to be done for creation of the evpn
                      node. Therefore by the time the
                      evpn-load-balancing request rolls around, the
                      request is rejected as the parent container does
                      not exist. As stated earlier, if the
                      default-operation is removed (causing a default of
                      merge) or replaced with a replace, the transaction
                      succeeds.

                    


                    

                    
A second interpretation to this
                      transaction is that the server should have created
                      the evpn node as part of the first request, and
                      that the none operation was implying that the node
                      had already been created.

                    


                    

                  

                

              

              

              

              If the server returns ok for the first
              <edit-config>, then it means it has successfully
              created the top two container nodes in the hierarchy:

              

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  <evpn >

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                <evpn-tables>

                

                then the second request should have succeeded.

          

        

        

          

            
 

              

              -Xiang Li

              
 

            

          

        

      

      

      

        
Mahesh Jethanandani

        
        


        

        

      

      

    

  



_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf











--94eb2c095ca436629905379ad158--


From nobody Thu Jul 14 09:48:30 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68112B04D for ; Thu, 14 Jul 2016 09:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kffp_y_4aLG4 for ; Thu, 14 Jul 2016 09:48:26 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0090.outbound.protection.outlook.com [104.47.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9CF12D09A for ; Thu, 14 Jul 2016 09:48:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+m1l7bDM5I8cg5/QOFF5dhBes+MLeUi1Rjhm4FFtCV8=; b=htsRV0TuNAIpPUkM6KXqiRN/vfA0qaJXirYSXoBGIcg7v1volkabMrh9rwFSObgsqv7AwOn7L84Paav3IAeznDiZCUMwX3cUDslj1e//GpngEE+q0xQ07ScgWq0gqutOVc6CnJZEHEiKGPPcKGUioHm8ooDmUv5o42pegYSh9w8=
Received: from BY2PR02MB2007.namprd02.prod.outlook.com (10.166.110.7) by BY2PR02MB2005.namprd02.prod.outlook.com (10.166.109.155) with Microsoft SMTP Server (TLS) id 15.1.534.14; Thu, 14 Jul 2016 16:48:25 +0000
Received: from BY2PR02MB2007.namprd02.prod.outlook.com ([10.166.110.7]) by BY2PR02MB2007.namprd02.prod.outlook.com ([10.166.110.7]) with mapi id 15.01.0539.019; Thu, 14 Jul 2016 16:48:25 +0000
From: Nick Weeds 
To: "netconf@ietf.org" 
Thread-Topic: RESTCONF JSON list questions
Thread-Index: AdHd36/dNWIKaogdRmSfDrmBOFq2yQADPVxwAACxs5A=
Date: Thu, 14 Jul 2016 16:48:25 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.weeds@metaswitch.com; 
x-originating-ip: [2620:104:4007:64:d0d9:be7b:90b8:25cf]
x-ms-office365-filtering-correlation-id: 58afa8d4-d4ed-4dd7-1a3f-08d3ac06aca8
x-microsoft-exchange-diagnostics: 1; BY2PR02MB2005; 6:OFPRSfDxDb2CfL9168PJbkkUkFbQPE8vKosk9ESWtLjFFQ4fQSqoTWkktDtU5U/lH7awwnnhTUuFpnAyRtffJSbWlPk2wZZkR2nMABIOeq2lF5JhblUz+BunXd45h+KGroth/GC1CIsO7ZAKRN8mxkQ7C1ibE+W2PMAvQjXGDiZcNYlYW3fm3db9Tho/gwFujzJwMk+jpuFbyIE0hEHmIRrA4da0qWq1TVdiB6q6e0YAwktQG2K/y7sHP2XJnyWJDo61dVT3Yy3bzKzh1zzLnp/C7OOTdnCc3ThY4LXzSSo=; 5:5tWGwI8bLmrDnVYHwVufmJoag/deL8X+4myLHJvmkM3jOj8Jk4Fi0u2ExvmSsiSQ0NKY1drCPhMr7TUBSPbpbOlmz3YTIm7JDfdgCbyGyRQvkOlTolEDuVwV52Ux3d+XAGSNmSd+WFdLWUQ1KNh3+A==; 24:Q3LJ18glXhCMbcxBQfdpgv45HxHSCYmFZ+FaPvQ/nhEdI2EOgxIitK2xRFdPYOq25nPaVtnzIMKbDsONFwVIS9uiy3TZnJFrEh221ysol24=; 7:vWTNu4td3P+JFevyhw2WuHaEOfgSHclSAkTqpQL5dHrSfWqUrf+/l6Oc263XkMMh++jEjte8H6CNfhd9dph0Cl3ZPMwgRXLY034YiX683n4VaNneMt0zRCjxp42yS6WYo8zq1kzkhkcRXJ1Fi1BotXFtvJaqz/lxfoYXs6J8lE1ur8ctZ1AbEunsvbuioO5hEHW3j+KKFHN9beh/OI5RwoDx5nEVuOP0lDeU+ucV/hFuqLpAyojOgp5yXrsy5090
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR02MB2005;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR02MB2005; BCL:0; PCL:0; RULEID:; SRVR:BY2PR02MB2005; 
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(2501003)(189998001)(5002640100001)(86362001)(2906002)(81166006)(77096005)(19300405004)(15975445007)(97736004)(92566002)(50986999)(19580395003)(107886002)(110136002)(6116002)(102836003)(790700001)(586003)(8936002)(3660700001)(68736007)(229853001)(105586002)(7696003)(99286002)(9686002)(7736002)(5003600100003)(7846002)(2351001)(3480700004)(74316002)(16236675004)(2900100001)(5640700001)(101416001)(5630700001)(10400500002)(106356001)(450100001)(19625215002)(122556002)(54356999)(1730700003)(87936001)(33656002)(81156014)(76576001)(8676002)(11100500001)(3280700002)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB2005; H:BY2PR02MB2007.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR02MB2007333A5905BFE3D0D2DEF6FB320BY2PR02MB2007namp_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2016 16:48:25.4039 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB2005
Archived-At: 
Subject: [Netconf] RESTCONF JSON list questions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 16:48:28 -0000

--_000_BY2PR02MB2007333A5905BFE3D0D2DEF6FB320BY2PR02MB2007namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have a couple of questions on RESTCONF handling of Yang lists when using =
JSON encoding.
Please can anybody answer or clarify these points ?
The current drafts don't seem to give definite answers (or might contain er=
rors), and it's hard to find answers in the archives.



(1)    Is it valid to perform a GET on an entire list rather than a single =
list entry ?

For example, is it valid to send a GET request for the interface list:

               GET /restconf/data/interfaces/interface

rather than a GET request on for a particular interface list entry:

               GET /restconf/data/interfaces/interface=3Deth1

Observations:

-        RFC 6020 seems to say that list entries are data nodes but lists a=
re not (sections 3, 4.2.2.4, 7.8).

-        draft-ietf-netconf-restconf-15 seems to say that list entries are =
data resources but lists are not (section 3.5).

-        draft-ietf-netconf-restconf-15 section 3.5.3 says that the URI mus=
t include the key values (so that it identifies a list entry rather than a =
list), but it doesn't say what happens if the list doesn't have any keys (a=
s is typical for a GET).

-        draft-ietf-netconf-restconf-15 section 4.3 says that a GET cannot =
return more than one instance when using XML encoding, but it doesn't say w=
hat happens when using other encodings (such as JSON).  This seems to keep =
the possibility of JSON providing more function than XML, although some WG =
mailing list discussions seem to have argued for keeping strict equivalence=
.


(2)    When a RESTCONF request contains a single list entry, when should it=
 be encoded as a JSON list and when should it be encoded as a single JSON o=
bject (examples in draft-ietf-netconf-restconf-15 vary) ?
For example, when should an album list entry be encoded like this:

        "example-jukebox:album" : [
          {
            "name" : "Wasting Light",
            ...
          }
        ]

and when should it be encoded like this:

        "example-jukebox:album" : {
          "name" : "Wasting Light",
          ...
        }

draft-ietf-netmod-yang-json-10 section 5.4 describes how to encode a list b=
ut not how to encode a single list entry in isolation.

Examples in draft-ietf-netconf-restconf-15 seem to vary:
- PUT examples seem to use a JSON list (section 4.5)
- GET example seem to use JSON list (section 5.3.2, D.3.9)
- POST examples seem to use a single JSON object without a JSON list (secti=
ons D.2.1, D.3.4, D.3.5).

The earlier "data format for list entry" discussion on the WG mailing list =
seems to indicate that the PUT and GET examples are correct but the POST ex=
amples are wrong.  Is that true?

               Nick.

--_000_BY2PR02MB2007333A5905BFE3D0D2DEF6FB320BY2PR02MB2007namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I have a couple of questions on RESTCON=
F handling of Yang lists when using JSON encoding.


Please can anybody answer or clarify th=
ese points ?


The current drafts don't seem to give d=
efinite answers (or might contain errors), and it's hard to find answers in=
 the archives.


 


 



(1)   
Is it valid to perform a GET on an entire list rath=
er than a single list entry ?


 


For example, is it valid to send a GET request for the i=
nterface list:


 


         &n=
bsp;    
GET /restconf/da=
ta/interfaces/interface


=
 


rather than a GET request on for a particular interface =
list entry:


 


         &n=
bsp;    
GET /restconf/da=
ta/interfaces/interface=3Deth1


=
 


Observations:



-       =
;
RFC 6020 seems to say that list entries are data no=
des but lists are not (sections 3, 4.2.2.4, 7.8).



-       =
;
draft-ietf-netconf-restconf-15 seems to say that li=
st entries are data resources but lists are not (section 3.5).


-       =
;
draft-ietf-netconf-restconf-15 section 3.5.3 says t=
hat the URI must include the key values (so that it identifies a list entry=
 rather than a list), but it doesn't say what happens if the list doesn't h=
ave any keys (as is typical for
 a GET).



-  =
;     
draft-ietf-netconf-restconf-15 section 4.3 s=
ays that a GET cannot return more than one instance when using XML encoding=
, but it doesn't say what happens when using other encodings (such as JSON)=
.  This seems to keep the possibility
 of JSON providing more function than XML, although some WG mailing list di=
scussions seem to have argued for keeping strict equivalence.


=
 



(2)   
When a RESTCONF request contains a single list entr=
y, when should it be encoded as a JSON list and when should it be encoded a=
s a single JSON object
(examples in draft-ietf-netconf-restconf-15 vary) ?


For example, when should an album list entry be encoded =
like this:



  &nbs=
p;     "example-jukebox:album" : [

          {

            "na=
me" : "Wasting Light",

            ...

          }

        ]



and when should it be encoded like this:



  &nbs=
p;     "example-jukebox:album" : {

          "name" : &=
quot;Wasting Light",

          ...

        }



draft-ietf-netmod-yang-json-10 section 5.4 describes how to encode a list b=
ut not how to encode a single list entry in isolation.

 


Examples in draft-ietf-netconf-restconf-15 seem to vary:=


- PUT examples seem to use a JSON list (section 4.5)

- GET example seem to use JSON list (section 5.3.2, D.3.9)

- POST examples seem to use a single JSON object without a JSON list (secti=
ons D.2.1, D.3.4, D.3.5).


 


The earlier "data format for list entry" discu=
ssion on the WG mailing list seems to indicate that the PUT and GET example=
s are correct but the POST examples are wrong.  Is that true?



            &nb=
sp;  Nick.






--_000_BY2PR02MB2007333A5905BFE3D0D2DEF6FB320BY2PR02MB2007namp_--


From nobody Thu Jul 14 11:47:46 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86812D1EA for ; Thu, 14 Jul 2016 11:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8r7hmDRstV5h for ; Thu, 14 Jul 2016 11:47:43 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B539212D176 for ; Thu, 14 Jul 2016 11:47:42 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 248E577D40C99; Thu, 14 Jul 2016 18:47:38 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6EIle3m019806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 18:47:41 GMT
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6EIleTY026078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 18:47:40 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 14:47:40 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Andy Bierman , Xiang Li 
Thread-Topic: [Netconf] What should a server response be?
Thread-Index: AQHR3esI0j4IVR1/2kW9+f8gjxD6tKAYQ0SQ
Date: Thu, 14 Jul 2016 18:47:40 +0000
Message-ID: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC9BD6US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 18:47:45 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCC9BD6US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SU1PIHRob3NlIGV4YW1wbGVzIGZyb20gTWFoZXNoIGFuZCBFaW5hciBzaG91bGQgYWxsIHN1Y2Nl
ZWQuDQoNCkJ1dCBhZnRlciB0aGUgMXN0IHJlcXVlc3QgSSBkb27igJl0IHRoaW5rIGEgPGdldC1j
b25maWc+IGlzIHJlcXVpcmVkIHRvIHJldHVybiBhbnkgZW1wdHkgTlAgY29udGFpbmVycy4gIFNv
IEnigJltIG5vdCBzdXJlIHRoYXQgSeKAmW0gdG90YWxseSBpbiBhZ3JlZW1lbnQgd2l0aCBYaWFu
ZyBMaS4gIEEgY3JlYXRlIG9mIGFuIE5QIGNvbnRhaW5lciBjYW4gcmV0dXJuIGFuIE9LIGJ1dCB0
aGVuIGEgc3Vic2VxdWVudCA8Z2V0LWNvbmZpZz4gY2FuIGZpbHRlciBvdXQgZW1wdHkgTlAgY29u
dGFpbmVycy4NCg0KUmV0dXJuaW5nIE5QIGNvbnRhaW5lcnMgKHdoZXRoZXIgdGhleSB3ZXJlIGV4
cGxpY2l0bHkgY3JlYXRlZCBvciBub3QpIHNlZW1zIGxpa2UgaXQgd291bGQgcHJvZHVjdCBhIGxv
dCBvZiB1bm5lY2Vzc2FyeSBub2lzZSBpbiBhIHJlc3BvbnNlLg0KDQpSZWdhcmRzLA0KSmFzb24N
Cg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogVGh1cnNkYXksIEp1bHkgMTQsIDIwMTYgMTI6MTYN
ClRvOiBYaWFuZyBMaQ0KQ2M6IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gV2hhdCBz
aG91bGQgYSBzZXJ2ZXIgcmVzcG9uc2UgYmU/DQoNCkhpLA0KDQpJIGNhbiBzZWUgdGhlIGNvbmZ1
c2lvbiBiZWNhdXNlIG9mIHRoZSBzbG9wcHkgdGV4dCBpbiBSRkMgNjI0MS4NCk5QIGNvbnRhaW5l
cnMgaGF2ZSBhbHdheXMgYmVlbiBhIHByb2JsZW0uICBUaGUgTkVUTU9EIFdHIGRpZCBhIHBvb3Ig
am9iDQpvZiBkZWZpbmluZyB0aGVtIGluIGFuIGludGVyb3BlcmFibGUgd2F5Lg0KDQpJTU8gdGhl
IHNlcnZlciBzaG91bGQgbm90IGRlbGV0ZSBOUCBjb250YWluZXJzIGZvciBleGFjdGx5IHRoZSBj
YXNlcyB5b3UgcG9pbnQgb3V0Lg0KVGhlIHNlcnZlciBkb2VzIG5vdCBrbm93IHRoZSBjbGllbnQn
cyBpbnRlbnRpb25zIHNvIHdoeSBpcyBpdCBkZWxldGluZyBub2Rlcz8NCkFsc28sIFlBTkcgMS4x
IFhQYXRoIHJ1bGVzIHRyZWF0IE5QIGNvbnRhaW5lcnMgYXMgaWYgdGhleSBhcmUgYWx3YXlzIHBy
ZXNlbnQuDQooU28gdGhlIHRleHQgYWJvdXQgTUFZIGRlbGV0ZSBOUCBjb250YWluZXJzIGlzIGV2
ZW4gbW9yZSBjb25mdXNpbmcpLg0KDQoNCkFuZHkNCg0KDQpPbiBUaHUsIEp1bCAxNCwgMjAxNiBh
dCA5OjEwIEFNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5
dW1hd29ya3MuY29tPj4gd3JvdGU6DQpIaSwNCg0KTWFoZXNoIGFza2VkIG1lIHRvIGJlIG1vcmUg
c3BlY2lmaWMuDQpJZiB0aGUgc2VydmVyIGlzIHJldHVybmluZyA8b2svPiBmb3IgZWRpdCAxIGJ1
dCB0aGUgY2FuZGlkYXRlIGRhdGFzdG9yZQ0KaXMgc3RpbGwgZW1wdHkgYWZ0ZXIgZWRpdCAxIHRo
ZW4gdGhpcyBpcyBhIHNlcnZlciBidWcuDQoNCkFuZHkNCg0KT24gV2VkLCBKdWwgMTMsIDIwMTYg
YXQgMjo1OCBQTSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlA
eXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KSGksDQoNClRoZSBpbXBsZW1lbnRhdGlvbiBoYXMgYnVn
cy4NClRoZSBSRkMgaXMgY2xlYXIgd3J0LyBvcGVyYXRpb249bm9uZSB2cyBtZXJnZSBvciByZXBs
YWNlLg0KDQoNCg0KQW5keQ0KDQoNCk9uIFdlZCwgSnVsIDEzLCAyMDE2IGF0IDI6NTUgUE0sIFhp
YW5nIExpIDx4aWFuZ2xpQHNlZ3Vlc29mdC5jb208bWFpbHRvOnhpYW5nbGlAc2VndWVzb2Z0LmNv
bT4+IHdyb3RlOg0KT24gNy8xMi8yMDE2IDg6NDUgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3Jv
dGU6DQoNCk9uIEp1bCAxMiwgMjAxNiwgYXQgOToyOCBBTSwgWGlhbmcgTGkgPHhpYW5nbGlAc2Vn
dWVzb2Z0LmNvbTxtYWlsdG86eGlhbmdsaUBzZWd1ZXNvZnQuY29tPj4gd3JvdGU6DQoNCk9uIDcv
MTEvMjAxNiAzOjQ3IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KVGhlIE9wZW5kYXls
aWdodCBjb250cm9sbGVyIGlzIGNvbnN0cnVjdGluZyB0aGlzIHBhcnRpY3VsYXIgc2V0IG9mIDxl
ZGl0LWNvbmZpZz4gcmVxdWVzdHMgYXMgcGFydCBvZiBhIHNpbmdsZSB0cmFuc2FjdGlvbi4gVGhl
IHJlc3BvbnNlIG9mIHRoZSBzZXJ2ZXIgaXMgdG8gcmVqZWN0IHRoZSBjb25maWd1cmF0aW9uIHRo
YXQgdGhlIHBhcnRpY3VsYXIgbm9kZSAoZXZwbiBjb250YWluZXIpIGRvZXMgbm90IGV4aXN0Lg0K
DQpIb3dldmVyLCBpZiB0aGUgZGVmYXVsdC1vcGVyYXRpb249bm9uZSBpcyByZW1vdmVkIG9yIGNo
YW5nZWQgdG8gcmVwbGFjZSwgdGhlIHNlcnZlciByZXNwb25kcyB3aXRoIGFuIFJQQyBPSy4NCg0K
SXMgdGhlIHNlcnZlciByaWdodCBpbiBpdHMgaW50ZXJwcmV0YXRpb24gb2Ygd2hhdCBSRkMgNjI0
MSBzYXlzPyBJbiBwYXJ0aWN1bGFyLCB0aGUgd2F5IHRoZSBzZXJ2ZXIgaXMgaW50ZXJwcmV0aW5n
IHRoaXMgcmVxdWVzdCBpcyBhcyBmb2xsb3dzIGZyb20gU2VjdGlvbiA3LjIgb2YgdGhlIFJGQzoN
Cg0KDQogICAgICAgICBub25lOiAgVGhlIHRhcmdldCBkYXRhc3RvcmUgaXMgdW5hZmZlY3RlZCBi
eSB0aGUgY29uZmlndXJhdGlvbg0KDQogICAgICAgICAgICBpbiB0aGUgPGNvbmZpZz4gcGFyYW1l
dGVyLCB1bmxlc3MgYW5kIHVudGlsIHRoZSBpbmNvbWluZw0KDQogICAgICAgICAgICBjb25maWd1
cmF0aW9uIGRhdGEgdXNlcyB0aGUgIm9wZXJhdGlvbiIgYXR0cmlidXRlIHRvIHJlcXVlc3QNCg0K
ICAgICAgICAgICAgYSBkaWZmZXJlbnQgb3BlcmF0aW9uLiAgSWYgdGhlIGNvbmZpZ3VyYXRpb24g
aW4gdGhlIDxjb25maWc+DQoNCiAgICAgICAgICAgIHBhcmFtZXRlciBjb250YWlucyBkYXRhIGZv
ciB3aGljaCB0aGVyZSBpcyBub3QgYQ0KDQogICAgICAgICAgICBjb3JyZXNwb25kaW5nIGxldmVs
IGluIHRoZSB0YXJnZXQgZGF0YXN0b3JlLCBhbiA8cnBjLWVycm9yPg0KDQogICAgICAgICAgICBp
cyByZXR1cm5lZCB3aXRoIGFuIDxlcnJvci10YWc+IHZhbHVlIG9mIGRhdGEtbWlzc2luZy4NCg0K
ICAgICAgICAgICAgVXNpbmcgIm5vbmUiIGFsbG93cyBvcGVyYXRpb25zIGxpa2UgImRlbGV0ZSIg
dG8gYXZvaWQNCg0KICAgICAgICAgICAgdW5pbnRlbnRpb25hbGx5IGNyZWF0aW5nIHRoZSBwYXJl
bnQgaGllcmFyY2h5IG9mIHRoZSBlbGVtZW50DQoNCiAgICAgICAgICAgIHRvIGJlIGRlbGV0ZWQu
DQoNCmFuZCB0aGVuIHRoaXM6DQoNCg0KICAgICAgb3BlcmF0aW9uOiAgRWxlbWVudHMgaW4gdGhl
IDxjb25maWc+IHN1YnRyZWUgTUFZIGNvbnRhaW4gYW4NCg0KICAgICAgICAgIm9wZXJhdGlvbiIg
YXR0cmlidXRlLCB3aGljaCBiZWxvbmdzIHRvIHRoZSBORVRDT05GIG5hbWVzcGFjZQ0KDQogICAg
ICAgICBkZWZpbmVkIGluIFNlY3Rpb24gMy4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y
ZmM2MjQxI3NlY3Rpb24tMy4xPi4gIFRoZSBhdHRyaWJ1dGUgaWRlbnRpZmllcyB0aGUgcG9pbnQg
aW4NCg0KICAgICAgICAgdGhlIGNvbmZpZ3VyYXRpb24gdG8gcGVyZm9ybSB0aGUgb3BlcmF0aW9u
IGFuZCBNQVkgYXBwZWFyIG9uDQoNCiAgICAgICAgIG11bHRpcGxlIGVsZW1lbnRzIHRocm91Z2hv
dXQgdGhlIDxjb25maWc+IHN1YnRyZWUuDQoNCg0KMXN0IHJlcXVlc3Q6DQoNCjxycGMgeG1sbnM9
InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIgbWVzc2FnZS1pZD0ibS0y
MyI+DQogIDxlZGl0LWNvbmZpZz4NCiAgICA8dGFyZ2V0Pg0KICAgICAgPGNhbmRpZGF0ZS8+DQog
ICAgPC90YXJnZXQ+DQogICAgPGVycm9yLW9wdGlvbj5yb2xsYmFjay1vbi1lcnJvcjwvZXJyb3It
b3B0aW9uPg0KICAgIDxjb25maWc+DQogICAgICA8ZXZwbiB4bWxucz0iaHR0cDovL2Npc2NvLmNv
bS9ucy95YW5nL0Npc2NvLUlPUy1YUi1sMnZwbi1jZmciPg0KICAgICAgICA8ZXZwbi10YWJsZXMv
Pg0KICAgICAgPC9ldnBuPg0KICAgIDwvY29uZmlnPg0KICA8L2VkaXQtY29uZmlnPg0KPC9ycGM+
DQojIw0KDQpUaGUgY29udGFpbmVyIGV2cG4gaW4gdGhpcyBjYXNlIGlzIGEgbm9uLXByZXNlbmNl
IGNvbnRhaW5lciBhbmQgZG9lcyBub3QgY29udGFpbiBhbnkgbWFuZGF0b3J5IGxlYWZzIG9yIGRl
ZmF1bHQgc3RhdGVtZW50cy4gVGhlIHNlcnZlciB0aGVyZWZvcmUgaW50ZXJwcmV0cyB0aGF0IG5v
dGhpbmcgaGFzIHRvIGJlIGRvbmUgaGVyZSwgYXMgaXQgaXMgbm90IHJlcXVpcmVkIHRvIGNyZWF0
ZSBhIGVtcHR5IGNvbnRhaW5lci4NCg0KDQoNCkkgdGhpbmsgdGhlIGNvbnRhaW5lciBub2RlIG5l
ZWRzIHRvIGJlIGNyZWF0ZWQgd2hlbiB5b3UgYXJlIG1lcmdpbmcgdG8gY3JlYXRlIG5ldyBub2Rl
cyBleHBsaWNpdGx5Lg0KUkZDNjAyMA0KNy41LiAgVGhlIGNvbnRhaW5lciBTdGF0ZW1lbnQNCiAg
IDcuNS44LiAgTkVUQ09ORiA8ZWRpdC1jb25maWc+IE9wZXJhdGlvbnMNCg0KDQogICAgV2hlbiBh
IE5FVENPTkYgc2VydmVyIHByb2Nlc3NlcyBhbiA8ZWRpdC1jb25maWc+IHJlcXVlc3QsIHRoZQ0K
DQogICAgZWxlbWVudHMgb2YgcHJvY2VkdXJlIGZvciB0aGUgY29udGFpbmVyIG5vZGUgYXJlOg0K
DQoNCg0KICAgICAgSWYgdGhlIG9wZXJhdGlvbiBpcyAibWVyZ2UiIG9yICJyZXBsYWNlIiwgdGhl
IG5vZGUgaXMgY3JlYXRlZCBpZg0KDQogICAgICBpdCBkb2VzIG5vdCBleGlzdC4NCg0KDQpJdCBt
YWtlcyBubyBzZW5zZSB0byBtZSBmb3IgdGhlIHNlcnZlciB0byByZXR1cm4gb2sgYnV0IGFjdHVh
bGx5IGRvZXMgbm90IGNyZWF0ZSB0aGF0DQpjb250YWluZXIgbm9kZSBpbiB0aGlzIGNhc2UuDQoN
CkFuZCB0aGF0IGlzIHRoZSBjbGFyaWZpY2F0aW9uIEkgYW0gc2Vla2luZy4gTm90ZSwgaXQgaXMg
YW4gZW1wdHkgbm9uLXByZXNlbmNlIGNvbnRhaW5lci4gU2hvdWxkIHRoZSBzZXJ2ZXIgY3JlYXRl
IHRoaXMgZW1wdHkgY29udGFpbmVyLCBhbmQgaWYgc28gaG93IHdvdWxkIGl0IGJlIHJlcHJlc2Vu
dGVkIGluIHRoZSBjb25maWcgdHJlZT8gSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHRoZSByZXF1
ZXN0IGlzIGZvbGxvd2VkIGJ5IGNoaWxkIG5vZGVzLiBXaGF0IGhhcHBlbnMgaWYgbm8gY2hpbGQg
bm9kZXMgYXJlIGNyZWF0ZWQ/DQoNCg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGRvZXMg
bm90IG1hdHRlciBpZiBpdCBpcyBhIHByZXNlbmNlIGNvbnRhaW5lciBvciBub3QgaW4gdGhpcyBj
YXNlDQosIG5vciBpZiB0aGVyZSBhcmUgY2hpbGQgbm9kZXMgaW5jbHVkZWQgIHRvIGJlIGNyZWF0
ZWQuDQoNCg0KDQoNCg0KVGhlIHNlcnZlciBtYXkgZGVsZXRlIGFuIGVtcHR5IGNvbnRhaW5lciBu
b2RlIGJ1dCBvbmx5IHdoZW4geW91IGRlbGV0aW5nIHN0dWZmOg0KDQoNCg0KSWYgYSBjb250YWlu
ZXIgZG9lcyBub3QgaGF2ZSBhICJwcmVzZW5jZSIgc3RhdGVtZW50IGFuZCB0aGUgbGFzdA0KDQog
ICBjaGlsZCBub2RlIGlzIGRlbGV0ZWQsIHRoZSBORVRDT05GIHNlcnZlciBNQVkgZGVsZXRlIHRo
ZSBjb250YWluZXIuDQoNCkZvciBhIGRlbGV0ZSBpdCBpcyBjbGVhci4gQnV0IHRoZSBSRkMgaXMg
c2lsZW50IGZvciBhIGNyZWF0ZSAoYW5kIHRoZSBkZWZhdWx0IG9wZXJhdGlvbiBvZiBtZXJnZSku
DQoNCkkgdGhpbmsgUkZDNjAyMCA3LjUuOC4gICJORVRDT05GIDxlZGl0LWNvbmZpZz4gT3BlcmF0
aW9ucyIgKGZvciBjb250YWluZXIgbm9kZSkNCmNvdmVycyB0aGlzIDoNCg0KLSAgICBXaGVuIGEg
TkVUQ09ORiBzZXJ2ZXIgcHJvY2Vzc2VzIGFuIDxlZGl0LWNvbmZpZz4gcmVxdWVzdCwgdGhlDQoN
Ci0gICAgZWxlbWVudHMgb2YgcHJvY2VkdXJlIGZvciB0aGUgY29udGFpbmVyIG5vZGUgYXJlOg0K
DQotDQoNCi0gICAgICBJZiB0aGUgb3BlcmF0aW9uIGlzICJtZXJnZSIgb3IgInJlcGxhY2UiLCB0
aGUgbm9kZSBpcyBjcmVhdGVkIGlmDQoNCi0gICAgICBpdCBkb2VzIG5vdCBleGlzdC4NCg0KDQoN
Ci0gICAgICBJZiB0aGUgb3BlcmF0aW9uIGlzICJjcmVhdGUiLCB0aGUgbm9kZSBpcyBjcmVhdGVk
IGlmIGl0IGRvZXMgbm90DQoNCi0gICAgICBleGlzdC4gIElmIHRoZSBub2RlIGFscmVhZHkgZXhp
c3RzLCBhICJkYXRhLWV4aXN0cyIgZXJyb3IgaXMNCg0KLSAgICAgIHJldHVybmVkLg0KDQoNCg0K
SWYgYSBub24tcHJlc2VuY2UgZW1wdHkgY29udGFpbmVyIGNhbiBiZSBkZWxldGVkLCB3aHkgc2hv
dWxkIGl0IGJlIGNyZWF0ZWQ/DQoNCg0KSXQgaXMgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHNlbmRp
bmcgYW4gPGVkaXQtY29uZmlnPiAgdG8gY3JlYXRlIHRoaXMgY29udGFpbmVyIGV4cGxpY2l0bHku
DQpJZiBhIGNsaWVudCB3YW50cyB0byBjcmVhdGUgKm9ubHkqIGEgY29udGFpbmVyIG5vZGUsIGl0
IGNhbiBjZXJ0YWlubHkgZG8gc28gd2l0aG91dA0KaGF2aW5nIHRvIHNwZWNpZnkgYW55IGNoaWxk
IGluc3RhbmNlIG5vZGVzLiBJZiB0aGUgc2VydmVyIHJldHVybnMgIk9rIiBmb3Igc3VjaA0KYSBy
ZXF1ZXN0IHRoZW4gaXQgbXVzdCBtZWFuIGl0IGhhcyBpbmRlZWQgY3JlYXRlZCB0aGUgY29udGFp
bmVyIG5vZGUuDQoNCkkgdGhpbmsgaXQgbWFrZXMgbGl0dGxlIHNlbnNlIGZvciBhIHNlcnZlciB0
byByZXR1cm4gIk9rIiBidXQgZG9lcyBub3QgY3JlYXRlDQp0aGUgY29udGFpbmVyIG5vZGUgKHRo
aW5raW5nIG5vdGhpbmcgbmVlZHMgdG8gYmUgZG9uZSBpZiB0aGVyZSBhcmUgbm8gY2hpbGQgbm9k
ZXMNCmluY2x1ZGVkIGluIHRoZSBzYW1lIHJlcXVlc3QpLiBUaGUgIk9rIiByZXNwb25zZSBtdXN0
IG1lYW4gc29tZXRoaW5nLCBpLmUuLA0KdGhlIGNyZWF0ZS9tZXJnZS9yZXBsYWNlIG9wZXJhdGlv
bnMgaGFzIGFjdHVhbGx5IHN1Y2NlZWRlZCBpbiBjcmVhdGluZyB0aGUNCmNvbnRhaW5lciBub2Rl
IGluIHF1ZXN0aW9uLg0KDQotWGlhbmcNCg0KDQoNClRoYW5rcy4NCg0KDQoNCg0KMm5kIHJlcXVl
c3Q6DQoNCjxycGMgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEu
MCIgbWVzc2FnZS1pZD0ibS0yNCI+DQogIDxlZGl0LWNvbmZpZz4NCiAgICA8dGFyZ2V0Pg0KICAg
ICAgPGNhbmRpZGF0ZS8+DQogICAgPC90YXJnZXQ+DQogICAgPGRlZmF1bHQtb3BlcmF0aW9uPm5v
bmU8L2RlZmF1bHQtb3BlcmF0aW9uPg0KICAgIDxlcnJvci1vcHRpb24+cm9sbGJhY2stb24tZXJy
b3I8L2Vycm9yLW9wdGlvbj4NCiAgICA8Y29uZmlnPg0KICAgICAgPGV2cG4geG1sbnM9Imh0dHA6
Ly9jaXNjby5jb20vbnMveWFuZy9DaXNjby1JT1MtWFItbDJ2cG4tY2ZnIj4NCiAgICAgICAgPGV2
cG4tdGFibGVzPg0KICAgICAgICAgIDxldnBuLWxvYWQtYmFsYW5jaW5nIHhtbG5zOmE9InVybjpp
ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIgYTpvcGVyYXRpb249InJlcGxhY2Ui
Pg0KICAgICAgICAgICAgPGVuYWJsZS8+DQogICAgICAgICAgICA8ZXZwbi1mbG93LWxhYmVsLz4N
CiAgICAgICAgICA8L2V2cG4tbG9hZC1iYWxhbmNpbmc+DQogICAgICAgIDwvZXZwbi10YWJsZXM+
DQogICAgICA8L2V2cG4+DQogICAgPC9jb25maWc+DQogIDwvZWRpdC1jb25maWc+DQo8L3JwYz4N
CiMjDQoNCkluIHRoZSBzZWNvbmQgcmVxdWVzdCwgdGhlIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUg
YWdhaW4gc2VlbXMgdG8gaW1wbHkgdGhhdCBub3RoaW5nIG5lZWRzIHRvIGJlIGRvbmUgZm9yIGNy
ZWF0aW9uIG9mIHRoZSBldnBuIG5vZGUuIFRoZXJlZm9yZSBieSB0aGUgdGltZSB0aGUgZXZwbi1s
b2FkLWJhbGFuY2luZyByZXF1ZXN0IHJvbGxzIGFyb3VuZCwgdGhlIHJlcXVlc3QgaXMgcmVqZWN0
ZWQgYXMgdGhlIHBhcmVudCBjb250YWluZXIgZG9lcyBub3QgZXhpc3QuIEFzIHN0YXRlZCBlYXJs
aWVyLCBpZiB0aGUgZGVmYXVsdC1vcGVyYXRpb24gaXMgcmVtb3ZlZCAoY2F1c2luZyBhIGRlZmF1
bHQgb2YgbWVyZ2UpIG9yIHJlcGxhY2VkIHdpdGggYSByZXBsYWNlLCB0aGUgdHJhbnNhY3Rpb24g
c3VjY2VlZHMuDQoNCkEgc2Vjb25kIGludGVycHJldGF0aW9uIHRvIHRoaXMgdHJhbnNhY3Rpb24g
aXMgdGhhdCB0aGUgc2VydmVyIHNob3VsZCBoYXZlIGNyZWF0ZWQgdGhlIGV2cG4gbm9kZSBhcyBw
YXJ0IG9mIHRoZSBmaXJzdCByZXF1ZXN0LCBhbmQgdGhhdCB0aGUgbm9uZSBvcGVyYXRpb24gd2Fz
IGltcGx5aW5nIHRoYXQgdGhlIG5vZGUgaGFkIGFscmVhZHkgYmVlbiBjcmVhdGVkLg0KDQoNCg0K
SWYgdGhlIHNlcnZlciByZXR1cm5zIG9rIGZvciB0aGUgZmlyc3QgPGVkaXQtY29uZmlnPiwgdGhl
biBpdCBtZWFucyBpdCBoYXMgc3VjY2Vzc2Z1bGx5IGNyZWF0ZWQgdGhlIHRvcCB0d28gY29udGFp
bmVyIG5vZGVzIGluIHRoZSBoaWVyYXJjaHk6DQogICAgICA8ZXZwbiA+DQogICAgICAgIDxldnBu
LXRhYmxlcz4NCg0KdGhlbiB0aGUgc2Vjb25kIHJlcXVlc3Qgc2hvdWxkIGhhdmUgc3VjY2VlZGVk
Lg0KDQoNCi1YaWFuZyBMaQ0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlA
Z21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGlu
ZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0KDQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCC9BD6US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw
YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y
bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT
dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5JTU8gdGhvc2UgZXhhbXBsZXMgZnJvbSBNYWhlc2ggYW5kIEVpbmFy
IHNob3VsZCBhbGwgc3VjY2VlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBhZnRlciB0aGUgMTxzdXA+c3Q8L3N1
cD4gcmVxdWVzdCBJIGRvbuKAmXQgdGhpbmsgYSAmbHQ7Z2V0LWNvbmZpZyZndDsgaXMgcmVxdWly
ZWQgdG8gcmV0dXJuIGFueSBlbXB0eSBOUCBjb250YWluZXJzLiZuYnNwOyBTbyBJ4oCZbSBub3Qg
c3VyZSB0aGF0IEnigJltIHRvdGFsbHkgaW4gYWdyZWVtZW50DQogd2l0aCBYaWFuZyBMaS4mbmJz
cDsgQSBjcmVhdGUgb2YgYW4gTlAgY29udGFpbmVyIGNhbiByZXR1cm4gYW4gT0sgYnV0IHRoZW4g
YSBzdWJzZXF1ZW50ICZsdDtnZXQtY29uZmlnJmd0OyBjYW4gZmlsdGVyIG91dCBlbXB0eSBOUCBj
b250YWluZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+UmV0dXJuaW5nIE5QIGNvbnRhaW5lcnMgKHdoZXRoZXIgdGhl
eSB3ZXJlIGV4cGxpY2l0bHkgY3JlYXRlZCBvciBub3QpIHNlZW1zIGxpa2UgaXQgd291bGQgcHJv
ZHVjdCBhIGxvdCBvZiB1bm5lY2Vzc2FyeSBub2lzZSBpbiBhIHJlc3BvbnNlLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFzb248bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxNCwg
MjAxNiAxMjoxNjxicj4NCjxiPlRvOjwvYj4gWGlhbmcgTGk8YnI+DQo8Yj5DYzo8L2I+IE5ldGNv
bmY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBXaGF0IHNob3VsZCBhIHNlcnZl
ciByZXNwb25zZSBiZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBj
YW4gc2VlIHRoZSBjb25mdXNpb24gYmVjYXVzZSBvZiB0aGUgc2xvcHB5IHRleHQgaW4gUkZDIDYy
NDEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O
UCBjb250YWluZXJzIGhhdmUgYWx3YXlzIGJlZW4gYSBwcm9ibGVtLiZuYnNwOyBUaGUgTkVUTU9E
IFdHIGRpZCBhIHBvb3Igam9iPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5vZiBkZWZpbmluZyB0aGVtIGluIGFuIGludGVyb3BlcmFibGUgd2F5Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8g
dGhlIHNlcnZlciBzaG91bGQgbm90IGRlbGV0ZSBOUCBjb250YWluZXJzIGZvciBleGFjdGx5IHRo
ZSBjYXNlcyB5b3UgcG9pbnQgb3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlcnZlciBkb2VzIG5vdCBrbm93IHRoZSBjbGllbnQncyBp
bnRlbnRpb25zIHNvIHdoeSBpcyBpdCBkZWxldGluZyBub2Rlcz88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIFlBTkcgMS4xIFhQYXRoIHJ1
bGVzIHRyZWF0IE5QIGNvbnRhaW5lcnMgYXMgaWYgdGhleSBhcmUgYWx3YXlzIHByZXNlbnQuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oU28gdGhl
IHRleHQgYWJvdXQgTUFZIGRlbGV0ZSBOUCBjb250YWluZXJzIGlzIGV2ZW4gbW9yZSBjb25mdXNp
bmcpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCA5OjEwIEFNLCBBbmR5IEJpZXJtYW4gJmx0
OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5
QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk1haGVzaCBhc2tlZCBtZSB0byBiZSBtb3JlIHNwZWNpZmljLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHNlcnZlciBp
cyByZXR1cm5pbmcgJmx0O29rLyZndDsgZm9yIGVkaXQgMSBidXQgdGhlIGNhbmRpZGF0ZSBkYXRh
c3RvcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PmlzIHN0aWxsIGVtcHR5IGFmdGVyIGVkaXQgMSB0aGVuIHRoaXMgaXMgYSBzZXJ2ZXIgYnVnLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1
bCAxMywgMjAxNiBhdCAyOjU4IFBNLCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzph
bmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
aSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbXBs
ZW1lbnRhdGlvbiBoYXMgYnVncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoZSBSRkMgaXMgY2xlYXIgd3J0LyBvcGVyYXRpb249bm9uZSB2cyBt
ZXJnZSBvciByZXBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVsIDEzLCAyMDE2IGF0IDI6NTUgUE0sIFhp
YW5nIExpICZsdDs8YSBocmVmPSJtYWlsdG86eGlhbmdsaUBzZWd1ZXNvZnQuY29tIiB0YXJnZXQ9
Il9ibGFuayI+eGlhbmdsaUBzZWd1ZXNvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcvMTIvMjAxNiA4OjQ1
IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAxMiwgMjAxNiwgYXQgOToyOCBBTSwgWGlh
bmcgTGkgJmx0OzxhIGhyZWY9Im1haWx0bzp4aWFuZ2xpQHNlZ3Vlc29mdC5jb20iIHRhcmdldD0i
X2JsYW5rIj54aWFuZ2xpQHNlZ3Vlc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzExLzIwMTYgMzo0
NyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9wZW5kYXlsaWdodCBjb250cm9sbGVy
IGlzIGNvbnN0cnVjdGluZyB0aGlzIHBhcnRpY3VsYXIgc2V0IG9mICZsdDtlZGl0LWNvbmZpZyZn
dDsgcmVxdWVzdHMgYXMgcGFydCBvZiBhIHNpbmdsZSB0cmFuc2FjdGlvbi4gVGhlIHJlc3BvbnNl
IG9mIHRoZSBzZXJ2ZXIgaXMgdG8gcmVqZWN0IHRoZSBjb25maWd1cmF0aW9uIHRoYXQgdGhlIHBh
cnRpY3VsYXIgbm9kZSAoZXZwbiBjb250YWluZXIpIGRvZXMgbm90IGV4aXN0LiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVy
LCBpZiB0aGUgZGVmYXVsdC1vcGVyYXRpb249bm9uZSBpcyByZW1vdmVkIG9yIGNoYW5nZWQgdG8g
cmVwbGFjZSwgdGhlIHNlcnZlciByZXNwb25kcyB3aXRoIGFuIFJQQyBPSy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlIHNlcnZlciBy
aWdodCBpbiBpdHMgaW50ZXJwcmV0YXRpb24gb2Ygd2hhdCBSRkMgNjI0MSBzYXlzPyBJbiBwYXJ0
aWN1bGFyLCB0aGUgd2F5IHRoZSBzZXJ2ZXIgaXMgaW50ZXJwcmV0aW5nIHRoaXMgcmVxdWVzdCBp
cyBhcyBmb2xsb3dzIGZyb20gU2VjdGlvbiA3LjIgb2YgdGhlIFJGQzo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgbm9uZTombmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9yOiNCNTFBMDAiPlRo
ZSB0YXJnZXQgZGF0YXN0b3JlIGlzIHVuYWZmZWN0ZWQgYnkgdGhlIGNvbmZpZ3VyYXRpb248bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNCNTFBMDAiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBpbiB0aGUgJmx0O2NvbmZpZyZndDsgcGFyYW1ldGVyLCB1bmxlc3MgYW5kIHVudGls
IHRoZSBpbmNvbWluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6I0I1MUEwMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gZGF0YSB1c2VzIHRoZSAmcXVv
dDtvcGVyYXRpb24mcXVvdDsgYXR0cmlidXRlIHRvIHJlcXVlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNCNTFBMDAiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIGRpZmZl
cmVudCBvcGVyYXRpb24uIDwvc3Bhbj4mbmJzcDtJZiB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUg
Jmx0O2NvbmZpZyZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1ldGVy
IGNvbnRhaW5zIGRhdGEgZm9yIHdoaWNoIHRoZXJlIGlzIG5vdCBhPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IGNvcnJlc3BvbmRpbmcgbGV2ZWwgaW4gdGhlIHRhcmdldCBkYXRhc3Rv
cmUsIGFuICZsdDtycGMtZXJyb3ImZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGlzIHJldHVybmVkIHdpdGggYW4gJmx0O2Vycm9yLXRhZyZndDsgdmFsdWUgb2YgZGF0YS1taXNz
aW5nLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVc2luZyAmcXVvdDtub25lJnF1
b3Q7IGFsbG93cyBvcGVyYXRpb25zIGxpa2UgJnF1b3Q7ZGVsZXRlJnF1b3Q7IHRvIGF2b2lkPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVuaW50ZW50aW9uYWxseSBjcmVhdGluZyB0
aGUgcGFyZW50IGhpZXJhcmNoeSBvZiB0aGUgZWxlbWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmbmJzcDt0byBiZSBkZWxldGVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0aGVuIHRoaXM6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wZXJh
dGlvbjombmJzcDsgRWxlbWVudHMgaW4gdGhlICZsdDtjb25maWcmZ3Q7IHN1YnRyZWUgTUFZIGNv
bnRhaW4gYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7b3BlcmF0aW9uJnF1b3Q7IGF0dHJpYnV0ZSwg
d2hpY2ggYmVsb25ncyB0byB0aGUgTkVUQ09ORiBuYW1lc3BhY2U8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVm
aW5lZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI0MSNzZWN0
aW9uLTMuMSIgdGFyZ2V0PSJfYmxhbmsiPlNlY3Rpb24gMy4xPC9hPi4mbmJzcDsgPHNwYW4gc3R5
bGU9ImNvbG9yOiNCNTFBMDAiPlRoZSBhdHRyaWJ1dGUgaWRlbnRpZmllcyB0aGUgcG9pbnQgaW48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNCNTFBMDAi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgY29u
ZmlndXJhdGlvbiB0byBwZXJmb3JtIHRoZSBvcGVyYXRpb24gYW5kIE1BWSBhcHBlYXIgb248bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNCNTFBMDAiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtdWx0aXBsZSBl
bGVtZW50cyB0aHJvdWdob3V0IHRoZSAmbHQ7Y29uZmlnJmd0OyBzdWJ0cmVlLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MTxzdXA+c3Q8L3N1cD4m
bmJzcDtyZXF1ZXN0Ojwvc3Bhbj48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbHQ7cnBjIHhtbG5zPSZxdW90
O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyBtZXNzYWdlLWlk
PSZxdW90O20tMjMmcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyAmbHQ7ZWRpdC1jb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dGFyZ2V0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2NhbmRpZGF0ZS8m
Z3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAm
bHQ7L3RhcmdldCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7ICZsdDtlcnJvci1vcHRpb24mZ3Q7cm9sbGJhY2stb24tZXJyb3ImbHQ7L2Vycm9y
LW9wdGlvbiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICZsdDtjb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXZwbiB4bWxucz0mcXVvdDs8YSBocmVm
PSJodHRwOi8vY2lzY28uY29tL25zL3lhbmcvQ2lzY28tSU9TLVhSLWwydnBuLWNmZyIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHA6Ly9jaXNjby5jb20vbnMveWFuZy9DaXNjby1JT1MtWFItbDJ2cG4tY2Zn
PC9hPiZxdW90OyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtldnBuLXRhYmxlcy8mZ3Q7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmbHQ7L2V2cG4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyAmbHQ7L2NvbmZpZyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Jm5ic3A7ICZsdDsvZWRpdC1jb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZsdDsvcnBjJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4j
Izwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY29udGFpbmVy
IGV2cG4gaW4gdGhpcyBjYXNlIGlzIGEgbm9uLXByZXNlbmNlIGNvbnRhaW5lciBhbmQgZG9lcyBu
b3QgY29udGFpbiBhbnkgbWFuZGF0b3J5IGxlYWZzIG9yIGRlZmF1bHQgc3RhdGVtZW50cy4gVGhl
IHNlcnZlciB0aGVyZWZvcmUgaW50ZXJwcmV0cyB0aGF0IG5vdGhpbmcgaGFzIHRvIGJlIGRvbmUg
aGVyZSwgYXMgaXQgaXMgbm90IHJlcXVpcmVkIHRvIGNyZWF0ZSBhIGVtcHR5IGNvbnRhaW5lci48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
PGJyPg0KSSB0aGluayB0aGUgY29udGFpbmVyIG5vZGUgbmVlZHMgdG8gYmUgY3JlYXRlZCB3aGVu
IHlvdSBhcmUgbWVyZ2luZyB0byBjcmVhdGUgbmV3IG5vZGVzIGV4cGxpY2l0bHkuPGJyPg0KUkZD
NjAyMCA8YnI+DQo3LjUuJm5ic3A7IFRoZSBjb250YWluZXIgU3RhdGVtZW50PGJyPg0KJm5ic3A7
Jm5ic3A7IDcuNS44LiZuYnNwOyBORVRDT05GICZsdDtlZGl0LWNvbmZpZyZndDsgT3BlcmF0aW9u
czxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgV2hl
biBhIE5FVENPTkYgc2VydmVyIHByb2Nlc3NlcyBhbiAmbHQ7ZWRpdC1jb25maWcmZ3Q7IHJlcXVl
c3QsIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBlbGVtZW50
cyBvZiBwcm9jZWR1cmUgZm9yIHRoZSBjb250YWluZXIgbm9kZSBhcmU6PG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IElmIHRoZSBvcGVyYXRpb24gaXMgJnF1b3Q7bWVyZ2UmcXVvdDsgb3IgJnF1
b3Q7cmVwbGFjZSZxdW90OywgdGhlIG5vZGUgaXMgY3JlYXRlZCBpZjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCBkb2VzIG5vdCBleGlzdC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SXQgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgZm9yIHRoZSBzZXJ2ZXIgdG8gcmV0
dXJuIG9rIGJ1dCBhY3R1YWxseSBkb2VzIG5vdCBjcmVhdGUgdGhhdDxicj4NCmNvbnRhaW5lciBu
b2RlIGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGF0IGlzIHRoZSBjbGFyaWZpY2F0
aW9uIEkgYW0gc2Vla2luZy4gTm90ZSwgaXQgaXMgYW4gZW1wdHkgbm9uLXByZXNlbmNlIGNvbnRh
aW5lci4gU2hvdWxkIHRoZSBzZXJ2ZXIgY3JlYXRlIHRoaXMgZW1wdHkgY29udGFpbmVyLCBhbmQg
aWYgc28gaG93IHdvdWxkIGl0IGJlIHJlcHJlc2VudGVkIGluIHRoZSBjb25maWcgdHJlZT8gSW4g
dGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHRoZSByZXF1ZXN0IGlzIGZvbGxvd2VkDQogYnkgY2hpbGQg
bm9kZXMuIFdoYXQgaGFwcGVucyBpZiBubyBjaGlsZCBub2RlcyBhcmUgY3JlYXRlZD88bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgaXQgZG9lcyBub3QgbWF0dGVyIGlmIGl0IGlz
IGEgcHJlc2VuY2UgY29udGFpbmVyIG9yIG5vdCBpbiB0aGlzIGNhc2U8YnI+DQosIG5vciBpZiB0
aGVyZSBhcmUgY2hpbGQgbm9kZXMgaW5jbHVkZWQmbmJzcDsgdG8gYmUgY3JlYXRlZC48YnI+DQo8
YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KVGhlIHNlcnZlciBtYXkgZGVsZXRlIGFu
IGVtcHR5IGNvbnRhaW5lciBub2RlIGJ1dCBvbmx5IHdoZW4geW91IGRlbGV0aW5nIHN0dWZmOjxi
cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5JZiBhIGNvbnRhaW5lciBkb2Vz
IG5vdCBoYXZlIGEgJnF1b3Q7cHJlc2VuY2UmcXVvdDsgc3RhdGVtZW50IGFuZCB0aGUgbGFzdDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjaGlsZCBub2RlIGlzIGRlbGV0ZWQs
IHRoZSBORVRDT05GIHNlcnZlciBNQVkgZGVsZXRlIHRoZSBjb250YWluZXIuPG86cD48L286cD48
L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkZvciBhIGRlbGV0ZSBpdCBpcyBjbGVhci4gQnV0IHRoZSBSRkMgaXMgc2lsZW50IGZvciBh
IGNyZWF0ZSAoYW5kIHRoZSBkZWZhdWx0IG9wZXJhdGlvbiBvZiBtZXJnZSkuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkkgdGhpbmsgUkZDNjAyMCA3
LjUuOC4mbmJzcDsgJnF1b3Q7TkVUQ09ORiAmbHQ7ZWRpdC1jb25maWcmZ3Q7IE9wZXJhdGlvbnMm
cXVvdDsgKGZvciBjb250YWluZXIgbm9kZSk8YnI+DQpjb3ZlcnMgdGhpcyA6IDxvOnA+PC9vOnA+
PC9wPg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gYSBORVRDT05GIHNlcnZlciBwcm9j
ZXNzZXMgYW4gJmx0O2VkaXQtY29uZmlnJmd0OyByZXF1ZXN0LCB0aGU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7IGVsZW1lbnRzIG9mIHByb2NlZHVyZSBmb3IgdGhl
IGNvbnRhaW5lciBub2RlIGFyZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tPG86cD48L286cD48
L3ByZT4NCjxwcmU+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0aGUgb3BlcmF0
aW9uIGlzICZxdW90O21lcmdlJnF1b3Q7IG9yICZxdW90O3JlcGxhY2UmcXVvdDssIHRoZSBub2Rl
IGlzIGNyZWF0ZWQgaWY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGl0IGRvZXMgbm90IGV4aXN0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoZSBvcGVyYXRpb24gaXMgJnF1b3Q7Y3JlYXRlJnF1
b3Q7LCB0aGUgbm9kZSBpcyBjcmVhdGVkIGlmIGl0IGRvZXMgbm90PG86cD48L286cD48L3ByZT4N
CjxwcmU+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleGlzdC4mbmJzcDsgSWYgdGhl
IG5vZGUgYWxyZWFkeSBleGlzdHMsIGEgJnF1b3Q7ZGF0YS1leGlzdHMmcXVvdDsgZXJyb3IgaXM8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJl
dHVybmVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBh
IG5vbi1wcmVzZW5jZSBlbXB0eSBjb250YWluZXIgY2FuIGJlIGRlbGV0ZWQsIHdoeSBzaG91bGQg
aXQgYmUgY3JlYXRlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KPGJyPg0KSXQgaXMgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHNlbmRpbmcgYW4gJmx0
O2VkaXQtY29uZmlnJmd0OyZuYnNwOyB0byBjcmVhdGUgdGhpcyBjb250YWluZXIgZXhwbGljaXRs
eS48YnI+DQpJZiBhIGNsaWVudCB3YW50cyB0byBjcmVhdGUgKm9ubHkqIGEgY29udGFpbmVyIG5v
ZGUsIGl0IGNhbiBjZXJ0YWlubHkgZG8gc28gd2l0aG91dA0KPGJyPg0KaGF2aW5nIHRvIHNwZWNp
ZnkgYW55IGNoaWxkIGluc3RhbmNlIG5vZGVzLiBJZiB0aGUgc2VydmVyIHJldHVybnMgJnF1b3Q7
T2smcXVvdDsgZm9yIHN1Y2g8YnI+DQphIHJlcXVlc3QgdGhlbiBpdCBtdXN0IG1lYW4gaXQgaGFz
IGluZGVlZCBjcmVhdGVkIHRoZSBjb250YWluZXIgbm9kZS48YnI+DQo8YnI+DQpJIHRoaW5rIGl0
IG1ha2VzIGxpdHRsZSBzZW5zZSBmb3IgYSBzZXJ2ZXIgdG8gcmV0dXJuICZxdW90O09rJnF1b3Q7
IGJ1dCBkb2VzIG5vdCBjcmVhdGUgPGJyPg0KdGhlIGNvbnRhaW5lciBub2RlICh0aGlua2luZyBu
b3RoaW5nIG5lZWRzIHRvIGJlIGRvbmUgaWYgdGhlcmUgYXJlIG5vIGNoaWxkIG5vZGVzPGJyPg0K
aW5jbHVkZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCkuIFRoZSAmcXVvdDtPayZxdW90OyByZXNwb25z
ZSBtdXN0IG1lYW4gc29tZXRoaW5nLCBpLmUuLDxicj4NCnRoZSBjcmVhdGUvbWVyZ2UvcmVwbGFj
ZSBvcGVyYXRpb25zIGhhcyBhY3R1YWxseSBzdWNjZWVkZWQgaW4gY3JlYXRpbmcgdGhlIDxicj4N
CmNvbnRhaW5lciBub2RlIGluIHF1ZXN0aW9uLjxicj4NCjxicj4NCi1YaWFuZzxicj4NCjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh
bmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MjxzdXA+
bmQ8L3N1cD4mbmJzcDtyZXF1ZXN0Ojwvc3Bhbj48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbHQ7cnBjIHht
bG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyBt
ZXNzYWdlLWlkPSZxdW90O20tMjQmcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPiZuYnNwOyAmbHQ7ZWRpdC1jb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dGFyZ2V0Jmd0Ozwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2Nh
bmRpZGF0ZS8mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw
OyZuYnNwOyAmbHQ7L3RhcmdldCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj
b2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZGVmYXVsdC1vcGVyYXRpb24mZ3Q7bm9u
ZSZsdDsvZGVmYXVsdC1vcGVyYXRpb24mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXJyb3Itb3B0aW9uJmd0O3JvbGxiYWNrLW9uLWVy
cm9yJmx0Oy9lcnJvci1vcHRpb24mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y29uZmlnJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2V2cG4geG1sbnM9
JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2Npc2NvLmNvbS9ucy95YW5nL0Npc2NvLUlPUy1YUi1sMnZw
bi1jZmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vY2lzY28uY29tL25zL3lhbmcvQ2lzY28tSU9T
LVhSLWwydnBuLWNmZzwvYT4mcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXZwbi10
YWJsZXMmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXZwbi1sb2FkLWJh
bGFuY2luZyB4bWxuczphPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNl
OjEuMCZxdW90OyBhOm9wZXJhdGlvbj0mcXVvdDtyZXBsYWNlJnF1b3Q7Jmd0Ozwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2VuYWJsZS8mZ3Q7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXZwbi1mbG93LWxhYmVsLyZn
dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvZXZwbi1sb2FkLWJhbGFuY2lu
ZyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvZXZwbi10YWJsZXMmZ3Q7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7
L2V2cG4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyAmbHQ7L2NvbmZpZyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7ICZsdDsvZWRpdC1jb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZsdDsvcnBjJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4jIzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBzZWNv
bmQgcmVxdWVzdCwgdGhlIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgYWdhaW4gc2VlbXMgdG8gaW1w
bHkgdGhhdCBub3RoaW5nIG5lZWRzIHRvIGJlIGRvbmUgZm9yIGNyZWF0aW9uIG9mIHRoZSBldnBu
IG5vZGUuIFRoZXJlZm9yZSBieSB0aGUgdGltZSB0aGUgZXZwbi1sb2FkLWJhbGFuY2luZyByZXF1
ZXN0IHJvbGxzIGFyb3VuZCwgdGhlIHJlcXVlc3QgaXMgcmVqZWN0ZWQgYXMgdGhlIHBhcmVudA0K
IGNvbnRhaW5lciBkb2VzIG5vdCBleGlzdC4gQXMgc3RhdGVkIGVhcmxpZXIsIGlmIHRoZSBkZWZh
dWx0LW9wZXJhdGlvbiBpcyByZW1vdmVkIChjYXVzaW5nIGEgZGVmYXVsdCBvZiBtZXJnZSkgb3Ig
cmVwbGFjZWQgd2l0aCBhIHJlcGxhY2UsIHRoZSB0cmFuc2FjdGlvbiBzdWNjZWVkcy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBzZWNvbmQg
aW50ZXJwcmV0YXRpb24gdG8gdGhpcyB0cmFuc2FjdGlvbiBpcyB0aGF0IHRoZSBzZXJ2ZXIgc2hv
dWxkIGhhdmUgY3JlYXRlZCB0aGUgZXZwbiBub2RlIGFzIHBhcnQgb2YgdGhlIGZpcnN0IHJlcXVl
c3QsIGFuZCB0aGF0IHRoZSBub25lIG9wZXJhdGlvbiB3YXMgaW1wbHlpbmcgdGhhdCB0aGUgbm9k
ZSBoYWQgYWxyZWFkeSBiZWVuIGNyZWF0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KPGJyPg0KSWYgdGhlIHNlcnZlciByZXR1cm5zIG9rIGZvciB0aGUgZmlyc3Qg
Jmx0O2VkaXQtY29uZmlnJmd0OywgdGhlbiBpdCBtZWFucyBpdCBoYXMgc3VjY2Vzc2Z1bGx5IGNy
ZWF0ZWQgdGhlIHRvcCB0d28gY29udGFpbmVyIG5vZGVzIGluIHRoZSBoaWVyYXJjaHk6PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXZwbiAmZ3Q7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICZsdDtldnBuLXRhYmxlcyZndDs8YnI+DQo8YnI+DQp0aGVuIHRoZSBzZWNv
bmQgcmVxdWVzdCBzaG91bGQgaGF2ZSBzdWNjZWVkZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQo8YnI+DQotWGlhbmcgTGk8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWhlc2gg
SmV0aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0i
X2JsYW5rIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A125E53CE190A749957C19483DC79F9F5CCC9BD6US70TWXCHMBA11z_--


From nobody Thu Jul 14 12:01:14 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA6412D873 for ; Thu, 14 Jul 2016 12:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYvpNs1g9FOj for ; Thu, 14 Jul 2016 12:01:09 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8D412D860 for ; Thu, 14 Jul 2016 12:00:55 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id o63so124926074vkg.1 for ; Thu, 14 Jul 2016 12:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N5m3WgiS+3GzCpMETconeqMeeJHlMI1Td3kNKwn1eOs=; b=f/VdzDjszYIJtuum3PHyfg5TDwHKq4r7geit2dBE5FxW1Z5WTsJHpa0l81PWgheSKI MSvUcU/woPeC+j5k0sobb+ykrujYrUnbefruD8KfGIsJeQ/ii5MSIYua/z1jvuzLTo8U 42IfMMZH29uxRmfTeaNalkCWmsMmDgo3PiZxgYXh8tvxFRYJVNuAEyavLVK0WwQ01YQU VlKtC1TzHQhQHe4dq+1ztWQQ5vKNGV3wN6Y8buOeltM55DwE+pdhA4CGGzQ4C/zd/brY IKefBoaruMoEsDE3gkMfXiE8WViDKK+EDUQa6+mOYxmYxHkdtGZ9AehKCwc4BaQUBHpu G3Ow==
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; bh=N5m3WgiS+3GzCpMETconeqMeeJHlMI1Td3kNKwn1eOs=; b=hpx3Si83rQPz8JOd4MgBzP0FWLNd7WZY56bTEuJF81rkH7E+buaj4KVaP/tHl7JRwA GCN1MP8b133EpiUvZCbCSTiXdBNaNeu8Jgkn/3loBxcHvnxJAn667zpCCoS0UtK/b917 N91jTccAGbxU1mG+vXg0/ZuB2UU4g5KB19J/zqNH7+aH8lw9TA/00EstfTTfIjj+4UNp NFchWlarU7VMGD1mIWMilDC9MxRsZj05QFlnuquxolXkRG/TAjAO59gom+YYT6x0BQd7 lyidMW1MuR71Gd4XqmVLryDRqotU5lyiQa8rHxic1gzNm3I0BiuE4lsMt9j8HQmqABtk Cp1g==
X-Gm-Message-State: ALyK8tLjRW/XKuw2jwZiW1pHVJgeqGH+Ld44ACVRCUtm1krjdb1s6Fviq0CTibXymEoG8IxCTeAAD4TPnYZo1A==
X-Received: by 10.159.35.112 with SMTP id 103mr7907268uae.55.1468522854091; Thu, 14 Jul 2016 12:00:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 12:00:53 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>    
From: Andy Bierman 
Date: Thu, 14 Jul 2016 12:00:53 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Content-Type: multipart/alternative; boundary=001a113ab81a10258c05379d1f67
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 19:01:13 -0000

--001a113ab81a10258c05379d1f67
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

The problem is this horrible text in the YANG RFC:

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.5.8

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.


This is a good example of why is a bad idea to define NETCONF protocol
details
in the YANG spec.

NETCONF itself never says it is OK for the server to delete edits from the
client.
(This is especially dumb in the candidate config because its sole purpose i=
s
to be a scratchpad for incremental edits)

So I have to say to server is allowed to delete the empty NP containers,
and the manager needs to guard against server implementations that delete
empty NP containers.

This sort of variability without purpose harms interoperability.


Andy





On Thu, Jul 14, 2016 at 11:47 AM, Sterne, Jason (Nokia - CA) <
jason.sterne@nokia.com> wrote:

> IMO those examples from Mahesh and Einar should all succeed.
>
>
>
> But after the 1st request I don=E2=80=99t think a  is require=
d to
> return any empty NP containers.  So I=E2=80=99m not sure that I=E2=80=99m=
 totally in
> agreement with Xiang Li.  A create of an NP container can return an OK bu=
t
> then a subsequent  can filter out empty NP containers.
>
>
>
> Returning NP containers (whether they were explicitly created or not)
> seems like it would product a lot of unnecessary noise in a response.
>
>
>
> Regards,
>
> Jason
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, July 14, 2016 12:16
> *To:* Xiang Li
> *Cc:* Netconf
> *Subject:* Re: [Netconf] What should a server response be?
>
>
>
> Hi,
>
>
>
> I can see the confusion because of the sloppy text in RFC 6241.
>
> NP containers have always been a problem.  The NETMOD WG did a poor job
>
> of defining them in an interoperable way.
>
>
>
> IMO the server should not delete NP containers for exactly the cases you
> point out.
>
> The server does not know the client's intentions so why is it deleting
> nodes?
>
> Also, YANG 1.1 XPath rules treat NP containers as if they are always
> present.
>
> (So the text about MAY delete NP containers is even more confusing).
>
>
>
>
>
> Andy
>
>
>
>
>
> On Thu, Jul 14, 2016 at 9:10 AM, Andy Bierman  wrote:
>
> Hi,
>
>
>
> Mahesh asked me to be more specific.
>
> If the server is returning  for edit 1 but the candidate datastore
>
> is still empty after edit 1 then this is a server bug.
>
>
>
> Andy
>
>
>
> On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman  wrote:
>
> Hi,
>
>
>
> The implementation has bugs.
>
> The RFC is clear wrt/ operation=3Dnone vs merge or replace.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li  wrote:
>
> On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>
>
>
> On Jul 12, 2016, at 9:28 AM, Xiang Li  wrote:
>
>
>
> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
>
> The Opendaylight controller is constructing this particular set of
>  requests as part of a single transaction. The response of t=
he
> server is to reject the configuration that the particular node (evpn
> container) does not exist.
>
>
>
> However, if the default-operation=3Dnone is removed or changed to replace=
,
> the server responds with an RPC OK.
>
>
>
> Is the server right in its interpretation of what RFC 6241 says? In
> particular, the way the server is interpreting this request is as follows
> from Section 7.2 of the RFC:
>
>
>
>          none:  The target datastore is unaffected by the configuration
>
>             in the  parameter, unless and until the incoming
>
>             configuration data uses the "operation" attribute to request
>
>             a different operation.  If the configuration in the 
>
>             parameter contains data for which there is not a
>
>             corresponding level in the target datastore, an 
>
>             is returned with an  value of data-missing.
>
>             Using "none" allows operations like "delete" to avoid
>
>             unintentionally creating the parent hierarchy of the element
>
>             to be deleted.
>
>
>
> and then this:
>
>
>
>       operation:  Elements in the  subtree MAY contain an
>
>          "operation" attribute, which belongs to the NETCONF namespace
>
>          defined in Section 3.1 .  The attribute identifies the point in
>
>          the configuration to perform the operation and MAY appear on
>
>          multiple elements throughout the  subtree.
>
>
>
>
>
> *1st request:*
>
>
>
> 
>
>   
>
>     
>
>       
>
>     
>
>     rollback-on-error
>
>     
>
>       
>
>         
>
>       
>
>     
>
>   
>
> 
>
> ##
>
>
>
> The container evpn in this case is a non-presence container and does not
> contain any mandatory leafs or default statements. The server therefore
> interprets that nothing has to be done here, as it is not required to
> create a empty container.
>
>
>
>
>
> I think the container node needs to be created when you are merging to
> create new nodes explicitly.
> RFC6020
> 7.5.  The container Statement
>    7.5.8.  NETCONF  Operations
>
>     When a NETCONF server processes an  request, the
>
>     elements of procedure for the container node are:
>
>
>
>       If the operation is "merge" or "replace", the node is created if
>
>       it does not exist.
>
>
>
> It makes no sense to me for the server to return ok but actually does not
> create that
> container node in this case.
>
>
>
> And that is the clarification I am seeking. Note, it is an empty
> non-presence container. Should the server create this empty container, an=
d
> if so how would it be represented in the config tree? In this particular
> case, the request is followed by child nodes. What happens if no child
> nodes are created?
>
>
>
>
> My understanding is that it does not matter if it is a presence container
> or not in this case
> , nor if there are child nodes included  to be created.
>
>
>
>
>
> The server may delete an empty container node but only when you deleting
> stuff:
>
>
> If a container does not have a "presence" statement and the last
>
>    child node is deleted, the NETCONF server MAY delete the container.
>
>
>
> For a delete it is clear. But the RFC is silent for a create (and the
> default operation of merge).
>
>
> I think RFC6020 7.5.8.  "NETCONF  Operations" (for container
> node)
> covers this :
>
> -    When a NETCONF server processes an  request, the
>
> -    elements of procedure for the container node are:
>
> -
>
> -      If the operation is "merge" or "replace", the node is created if
>
> -      it does not exist.
>
>
>
> -      If the operation is "create", the node is created if it does not
>
> -      exist.  If the node already exists, a "data-exists" error is
>
> -      returned.
>
>
>
>
> If a non-presence empty container can be deleted, why should it be create=
d?
>
>
>
> It is because the client is sending an   to create this
> container explicitly.
> If a client wants to create *only* a container node, it can certainly do
> so without
> having to specify any child instance nodes. If the server returns "Ok" fo=
r
> such
> a request then it must mean it has indeed created the container node.
>
> I think it makes little sense for a server to return "Ok" but does not
> create
> the container node (thinking nothing needs to be done if there are no
> child nodes
> included in the same request). The "Ok" response must mean something, i.e=
.,
> the create/merge/replace operations has actually succeeded in creating th=
e
> container node in question.
>
> -Xiang
>
>
>
>
> Thanks.
>
>
>
>
>
> *2nd request:*
>
>
>
> 
>
>   
>
>     
>
>       
>
>     
>
>     none
>
>     rollback-on-error
>
>     
>
>       
>
>         
>
>            xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replac=
e">
>
>             
>
>             
>
>           
>
>         
>
>       
>
>     
>
>   
>
> 
>
> ##
>
>
>
> In the second request, the default-operation=3Dnone again seems to imply
> that nothing needs to be done for creation of the evpn node. Therefore by
> the time the evpn-load-balancing request rolls around, the request is
> rejected as the parent container does not exist. As stated earlier, if th=
e
> default-operation is removed (causing a default of merge) or replaced wit=
h
> a replace, the transaction succeeds.
>
>
>
> A second interpretation to this transaction is that the server should hav=
e
> created the evpn node as part of the first request, and that the none
> operation was implying that the node had already been created.
>
>
>
>
>
> If the server returns ok for the first , then it means it ha=
s
> successfully created the top two container nodes in the hierarchy:
>
>       
>
>         
>
> then the second request should have succeeded.
>
>
>
> -Xiang Li
>
>
>
> Mahesh Jethanandani
>
> mjethanandani@gmail.com
>
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
>
>
>

--001a113ab81a10258c05379d1f67
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The problem is this horrible text i=
n the YANG RFC:


   If a container does not have a "prese=
nce" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

This is a good example of why is a bad idea=
 to define NETCONF protocol details
in the YANG spec.
<=
br>
NETCONF itself never says it is OK for the server to delete e=
dits from the client.
(This is especially dumb in the candidate c=
onfig because its sole purpose is
to be a scratchpad for incremen=
tal edits)

So I have to say to server is allowed t=
o delete the empty NP containers,
and the manager needs to guard =
against server implementations that delete
empty NP containers.

This sort of variability without purpose harms inte=
roperability.


Andy





On Thu, Jul 14, 2016 at 11:47 AM, Ste=
rne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:=












IMO those examples from M=
ahesh and Einar should all succeed.


=C2=A0


But after the 1st request I don=E2=80=99t think a <get-config> is required to retur=
n any empty NP containers.=C2=A0 So I=E2=80=99m not sure that I=E2=80=99m t=
otally in agreement
 with Xiang Li.=C2=A0 A create of an NP container can return an OK but then=
 a subsequent <get-config> can filter out empty NP containers.=



=C2=A0


Returning NP containers (=
whether they were explicitly created or not) seems like it would product a =
lot of unnecessary noise in a response.


=C2=A0


Regards,


Jason


=C2=A0




From: Netconf =
[mailto:netco=
nf-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: Thursday, July 14, 2016 12:16

To: Xiang Li

Cc: Netconf

Subject: Re: [Netconf] What should a server response be?




=C2=A0




Hi,




=C2=A0






I can see the confusion because of the sloppy text i=
n RFC 6241.






NP containers have always been a problem.=C2=A0 The =
NETMOD WG did a poor job






of defining them in an interoperable way.<=
/u>






=C2=A0






IMO the server should not delete NP containers for e=
xactly the cases you point out.






The server does not know the client's intentions=
 so why is it deleting nodes?






Also, YANG 1.1 XPath rules treat NP containers as if=
 they are always present.






(So the text about MAY delete NP containers is even =
more confusing).






=C2=A0






=C2=A0






Andy






=C2=A0








=C2=A0




On Thu, Jul 14, 2016 at 9:10 AM, Andy Bierman <andy@yumaworks.com> wrote:




Hi,




=C2=A0






Mahesh asked me to be more specific.





If the server is returning <ok/> for edit 1 bu=
t the candidate datastore






is still empty after edit 1 then this is a server bu=
g.






=C2=A0






Andy






=C2=A0




On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman <andy@yumaworks.com> wrote:




Hi,




=C2=A0






The implementation has bugs.






The RFC is clear wrt/ operation=3Dnone vs merge or r=
eplace.






=C2=A0






=C2=A0






=C2=A0






Andy






=C2=A0








=C2=A0




On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li <xiangli@seguesoft.com<=
/a>> wrote:






On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:<=
/u>






=C2=A0







=C2=A0








On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:<=
/u>








The Opendaylight controller is constructing this par=
ticular set of <edit-config> requests as part of a single transaction=
. The response of the server is to reject the configuration that the partic=
ular node (evpn container) does not exist.=C2=A0






=C2=A0






However, if the default-operation=3Dnone is removed =
or changed to replace, the server responds with an RPC OK.





=C2=A0






Is the server right in its interpretation of what RF=
C 6241 says? In particular, the way the server is interpreting this request=
 is as follows from Section 7.2 of the RFC:






=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 none:=C2=A0 The target datastore is unaffected by the configuratio=
n


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the <config> parameter, unless and unt=
il the incoming


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 configuration data uses the "operation&quo=
t; attribute to request


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 a different operation. =C2=A0If the conf=
iguration in the <config>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 par=
ameter contains data for which there is not a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cor=
responding level in the target datastore, an <rpc-error>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is =
returned with an <error-tag> value of data-missing.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Usi=
ng "none" allows operations like "delete" to avoid


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uni=
ntentionally creating the parent hierarchy of the element

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0to =
be deleted.






=C2=A0






and then this:






=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operation:=C2=A0 Elements in the <co=
nfig> subtree MAY contain an


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "operation"=
 attribute, which belongs to the NETCONF namespace


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined in Section=
 3.1.=C2=A0 The attribute identifies the =
point in


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 the configuration to perform the operation and MAY appear on


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 multiple elements throughout the <config> subtree.






=C2=A0






=C2=A0








1st=C2=A0request:






=C2=A0






<rpc xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0" message-id=3D"m-23&qu=
ot;>






=C2=A0 <edit-con=
fig>






=C2=A0=C2=A0=C2=A0 =
<target>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <candidate/>






=C2=A0=C2=A0=C2=A0 =
</target>






=C2=A0=C2=A0=C2=A0 =
<error-option>rollback-on-error</error-option>=







=C2=A0=C2=A0=C2=A0 =
<config>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <evpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-X=
R-l2vpn-cfg">






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-tables/>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </evpn>






=C2=A0=C2=A0=C2=A0 =
</config>






=C2=A0 </edit-co=
nfig>






</rpc>=







##=







=C2=A0






The container evpn in this case is a non-presence co=
ntainer and does not contain any mandatory leafs or default statements. The=
 server therefore interprets that nothing has to be done here, as it is not=
 required to create a empty container.






=C2=A0












I think the container node needs to be created when you are merging to crea=
te new nodes explicitly.

RFC6020 

7.5.=C2=A0 The container Statement

=C2=A0=C2=A0 7.5.8.=C2=A0 NETCONF <edit-config> Operations






=C2=A0=C2=A0=C2=A0 When a NETCONF server processes an <edit-config&=
gt; request, the


=C2=A0=C2=A0=C2=A0 elements of procedure for the container node are:


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operation is "merge" o=
r "replace", the node is created if


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it does not exist.


=C2=A0


It makes no sense to me for the server to return ok =
but actually does not create that

container node in this case.










=C2=A0




And that is the clarification I am seeking. Note, it=
 is an empty non-presence container. Should the server create this empty co=
ntainer, and if so how would it be represented in the config tree? In this =
particular case, the request is followed
 by child nodes. What happens if no child nodes are created?<=
/p>





=C2=A0








My understanding is that it does not matter if it is a presence container o=
r not in this case

, nor if there are child nodes included=C2=A0 to be created.






















The server may delete an empty container node but only when you deleting st=
uff:








If a container does not have a "presence" statement and the =
last


=C2=A0=C2=A0 child node is deleted, the NETCONF server MAY delete the =
container.










=C2=A0




For a delete it is clear. But the RFC is silent for =
a create (and the default operation of merge).






I think RFC6020 7.5.8.=C2=A0 "NETCONF <edit-config> Operations&q=
uot; (for container node)

covers this : 


-=C2=A0=C2=A0=C2=A0 When a NETCONF server processes an <edit-config=
> request, the


-=C2=A0=C2=A0=C2=A0 elements of procedure for the container node are:<=
u>


-


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operation is "merge" =
or "replace", the node is created if


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it does not exist.


=C2=A0=C2=A0=C2=A0=C2=A0 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operation is "create"=
, the node is created if it does not


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exist.=C2=A0 If the node already exist=
s, a "data-exists" error is


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 returned.













If a non-presence empty container can be deleted, wh=
y should it be created?








It is because the client is sending an <edit-config>=C2=A0 to create =
this container explicitly.

If a client wants to create *only* a container node, it can certainly do so=
 without


having to specify any child instance nodes. If the server returns "Ok&=
quot; for such

a request then it must mean it has indeed created the container node.



I think it makes little sense for a server to return "Ok" but doe=
s not create 

the container node (thinking nothing needs to be done if there are no child=
 nodes

included in the same request). The "Ok" response must mean someth=
ing, i.e.,

the create/merge/replace operations has actually succeeded in creating the =


container node in question.



-Xiang










=C2=A0






Thanks.




























2nd=C2=A0request:






=C2=A0






<rpc xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0" message-id=3D"m-24&qu=
ot;>






=C2=A0 <edit-con=
fig>






=C2=A0=C2=A0=C2=A0 =
<target>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <candidate/>






=C2=A0=C2=A0=C2=A0 =
</target>






=C2=A0=C2=
=A0=C2=A0 <default-operation>none</default-operation>=







=C2=A0=C2=A0=C2=A0 =
<error-option>rollback-on-error</error-option>=







=C2=A0=C2=A0=C2=A0 =
<config>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <evpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-X=
R-l2vpn-cfg">






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-tables>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-load-balancing xmlns:a=3D&quo=
t;urn:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replace=
">






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <enable/><=
/u>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-flow-label/>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn-load-balancing>=







=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </evpn-tables>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </evpn>






=C2=A0=C2=A0=C2=A0 =
</config>






=C2=A0 </edit-co=
nfig>






</rpc>=







##=







=C2=A0




In the second request, the default-operation=3Dnone =
again seems to imply that nothing needs to be done for creation of the evpn=
 node. Therefore by the time the evpn-load-balancing request rolls around, =
the request is rejected as the parent
 container does not exist. As stated earlier, if the default-operation is r=
emoved (causing a default of merge) or replaced with a replace, the transac=
tion succeeds.






=C2=A0






A second interpretation to this transaction is that =
the server should have created the evpn node as part of the first request, =
and that the none operation was implying that the node had already been cre=
ated.






=C2=A0












If the server returns ok for the first <edit-config>, then it means i=
t has successfully created the top two container nodes in the hierarchy:=





=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <evpn >




=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-tables>



then the second request should have succeeded.
















-Xiang Li














=C2=A0






Mahesh Jethanandani







=C2=A0




=C2=A0




=C2=A0






_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




=C2=A0






=C2=A0








=C2=A0












--001a113ab81a10258c05379d1f67--


From nobody Thu Jul 14 12:03:54 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF74112D103 for ; Thu, 14 Jul 2016 12:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NrA06b46qUyP for ; Thu, 14 Jul 2016 12:03:51 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068E112D1D0 for ; Thu, 14 Jul 2016 12:03:50 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 752BD8107C2FB for ; Thu, 14 Jul 2016 19:03:47 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6EJ3nHk010895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 14 Jul 2016 19:03:50 GMT
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6EJ3nNq008524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Jul 2016 19:03:49 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 15:03:16 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Netconf 
Thread-Topic:  in a server that supports both writable-running and candidate
Thread-Index: AdHeAl/GLPvbP2zwTVylVCsJWBbO+A==
Date: Thu, 14 Jul 2016 19:03:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC9C29US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 19:03:53 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCC9C29US70TWXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I'm looking for opinions on how a client & server might interact for the  RPC when a server supports both writable-running and candidate DS.

I suspect this is an unusual situation -> does anyone out there work with o=
r have a server implementation that supports both ?

The spirit of a  is to reserve exclusive access to alter the configur=
ation of the device, and to prevent other clients (or management interfaces=
) from altering the config in the meantime.  I realize that in theory the l=
ocks are "per-DS" (i.e. independant) but I think that might be too simplist=
ic for a system with both writable-running and candidate.

In a server that supports both writable-running & candidate, it seems to ma=
ke sense that a  of the running DS would also cause the server to imp=
licitly lock the candidate (or at least reject a lock request of the candid=
ate).  Otherwise (i.e. accepting a subsequent lock of the candidate) the cl=
ient may assume since it has the candidate lock then it has the exclusive r=
ights to the config and can happily edit & commit the config.  It would be =
confusing to error on the commit (due to locking) after having accepted a l=
ock.

Similarly for the reverse situation -> if a client takes a candidate =
 then couldn't it assume that nobody can subsequently block their commit by=
 taking a lock of the running DS ?

It seems like the server should manage this interaction and avoid giving an=
 "OK" to clients taking the two locks on the two datastores.

On the other hand this could all be left up to the clients to deal with.  C=
lients would have to see that a server has both a writeable-running and a c=
andidate DS and take a lock of both.   But that would require all clients t=
o have that behavior (instead of the server that supports the 2 DSes dealin=
g with this).  It also has race conditions where the client takes 1 lock bu=
t someone else gets the second lock.

Opinions appreciated.
Regards,
Jason


--_000_A125E53CE190A749957C19483DC79F9F5CCC9C29US70TWXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


I’m looking for opinions on how a client & server might inte=
ract for the <lock> RPC when a server supports both writable-running =
and candidate DS.  


 


I suspect this is an unusual situation -> does anyone out there wor=
k with or have a server implementation that supports both ?


 


The spirit of a <lock> is to reserve exclusive access to alter t=
he configuration of the device, and to prevent other clients (or management=
 interfaces) from altering the config in the meantime.  I realize that=
 in theory the locks are “per-DS” (i.e. independant)
but I think that might be too simplistic for a system with both writable-ru=
nning and candidate.


 


In a server that supports both writable-running & candidate, it se=
ems to make sense that a <lock> of the running DS would also cause th=
e server to implicitly lock the candidate (or at least reject a lock reques=
t of the candidate).  Otherwise (i.e. accepting
a subsequent lock of the candidate) the client may assume since it has the =
candidate lock then it has the exclusive rights to the config and can happi=
ly edit & commit the config.  It would be confusing to error on th=
e commit (due to locking) after having accepted
a lock.


 


Similarly for the reverse situation -> if a client takes a candidat=
e <lock> then couldn’t it assume that nobody can subsequently b=
lock their commit by taking a lock of the running DS ?


 


It seems like the server should manage this interaction and avoid givi=
ng an “OK” to clients taking the two locks on the two datastore=
s.


 


On the other hand this could all be left up to the clients to deal wit=
h.  Clients would have to see that a server has both a writeable-runni=
ng and a candidate DS and take a lock of both.   But that would r=
equire all clients to have that behavior (instead
of the server that supports the 2 DSes dealing with this).  It also ha=
s race conditions where the client takes 1 lock but someone else gets the s=
econd lock.


 


Opinions appreciated.


Regards,


Jason 


 





--_000_A125E53CE190A749957C19483DC79F9F5CCC9C29US70TWXCHMBA11z_--


From nobody Thu Jul 14 12:08:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03912D1D0 for ; Thu, 14 Jul 2016 12:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2mqLpgq-0GqA for ; Thu, 14 Jul 2016 12:08:07 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648E312D0C1 for ; Thu, 14 Jul 2016 12:08:07 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id BBF837AF4088F; Thu, 14 Jul 2016 19:08:02 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6EJ85l8005347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 19:08:05 GMT
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6EJ85vm023115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 19:08:05 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 15:08:05 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Andy Bierman 
Thread-Topic: [Netconf] What should a server response be?
Thread-Index: AQHR3esI0j4IVR1/2kW9+f8gjxD6tKAYQ0SQgABICoD//73wYA==
Date: Thu, 14 Jul 2016 19:08:05 +0000
Message-ID: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC9C5DUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 19:08:10 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCC9C5DUS70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBndWVzcyBJIGRvbuKAmXQgcmVhbGx5IHNlZSBOUC1jb250YWluZXJzIGFzIOKAnGNvbmZpZ+KA
nS4gIFRoZXkgYXJlIGp1c3Qgc3RydWN0dXJlIGFuZCBmaWx0ZXJlZCBvdXQgd2hlbiBlbXB0eS4g
IEkgZG9u4oCZdCByZWFsbHkgc2VlIHRoaXMgYXMgdGhlIHNlcnZlciDigJxkZWxldGluZ+KAnSB0
aG9zZSBjb250YWluZXJzLiAgSXQganVzdCBzdXBwcmVzc2VzIHRoZW0gaW4gPGdldC1jb25maWc+
IG91dHB1dC4NCg0KVGhlIHNlcnZlciBzaG91bGQgbm90IGVycm9yIGluIHRoZSBjYXNlcyBNYWhl
c2ggJiBFaW5hciBzaG93IC0+IHRoZSBwcmVzZW5jZS9leGlzdGVuY2Ugb2YgTlAtY29udGFpbmVy
cyBzaG91bGRu4oCZdCByZWFsbHkgYWZmZWN0IGJlaGF2aW9yIChzaW5jZSB0aGV5IGFyZW7igJl0
IHJlYWxseSBjb25maWcpLg0KDQpCdXQgSeKAmW0gbm90IHBvc2l0aXZlIHdoYXQgeW91IG1lYW4g
Ynkg4oCcbWFuYWdlciBuZWVkcyB0byBndWFyZOKAnS4gIERvIHlvdSBhZ3JlZSB0aGF0IHRoZSBz
ZXJ2ZXIgc2hvdWxkIG5vdCBlcnJvciBpbiB0aG9zZSBjYXNlcyBiZWxvdyA/DQoNCkphc29uDQoN
CkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFRo
dXJzZGF5LCBKdWx5IDE0LCAyMDE2IDE1OjAxDQpUbzogU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBD
QSkNCkNjOiBYaWFuZyBMaTsgTmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBXaGF0IHNo
b3VsZCBhIHNlcnZlciByZXNwb25zZSBiZT8NCg0KSGksDQoNClRoZSBwcm9ibGVtIGlzIHRoaXMg
aG9ycmlibGUgdGV4dCBpbiB0aGUgWUFORyBSRkM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDIwYmlzLTE0I3NlY3Rpb24tNy41LjgNCg0KDQog
ICBJZiBhIGNvbnRhaW5lciBkb2VzIG5vdCBoYXZlIGEgInByZXNlbmNlIiBzdGF0ZW1lbnQgYW5k
IHRoZSBsYXN0DQoNCiAgIGNoaWxkIG5vZGUgaXMgZGVsZXRlZCwgdGhlIE5FVENPTkYgc2VydmVy
IE1BWSBkZWxldGUgdGhlIGNvbnRhaW5lci4NCg0KDQpUaGlzIGlzIGEgZ29vZCBleGFtcGxlIG9m
IHdoeSBpcyBhIGJhZCBpZGVhIHRvIGRlZmluZSBORVRDT05GIHByb3RvY29sIGRldGFpbHMNCmlu
IHRoZSBZQU5HIHNwZWMuDQoNCk5FVENPTkYgaXRzZWxmIG5ldmVyIHNheXMgaXQgaXMgT0sgZm9y
IHRoZSBzZXJ2ZXIgdG8gZGVsZXRlIGVkaXRzIGZyb20gdGhlIGNsaWVudC4NCihUaGlzIGlzIGVz
cGVjaWFsbHkgZHVtYiBpbiB0aGUgY2FuZGlkYXRlIGNvbmZpZyBiZWNhdXNlIGl0cyBzb2xlIHB1
cnBvc2UgaXMNCnRvIGJlIGEgc2NyYXRjaHBhZCBmb3IgaW5jcmVtZW50YWwgZWRpdHMpDQoNClNv
IEkgaGF2ZSB0byBzYXkgdG8gc2VydmVyIGlzIGFsbG93ZWQgdG8gZGVsZXRlIHRoZSBlbXB0eSBO
UCBjb250YWluZXJzLA0KYW5kIHRoZSBtYW5hZ2VyIG5lZWRzIHRvIGd1YXJkIGFnYWluc3Qgc2Vy
dmVyIGltcGxlbWVudGF0aW9ucyB0aGF0IGRlbGV0ZQ0KZW1wdHkgTlAgY29udGFpbmVycy4NCg0K
VGhpcyBzb3J0IG9mIHZhcmlhYmlsaXR5IHdpdGhvdXQgcHVycG9zZSBoYXJtcyBpbnRlcm9wZXJh
YmlsaXR5Lg0KDQoNCkFuZHkNCg0KDQoNCg0KDQpPbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCAxMTo0
NyBBTSwgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSkgPGphc29uLnN0ZXJuZUBub2tpYS5jb208
bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20+PiB3cm90ZToNCklNTyB0aG9zZSBleGFtcGxl
cyBmcm9tIE1haGVzaCBhbmQgRWluYXIgc2hvdWxkIGFsbCBzdWNjZWVkLg0KDQpCdXQgYWZ0ZXIg
dGhlIDFzdCByZXF1ZXN0IEkgZG9u4oCZdCB0aGluayBhIDxnZXQtY29uZmlnPiBpcyByZXF1aXJl
ZCB0byByZXR1cm4gYW55IGVtcHR5IE5QIGNvbnRhaW5lcnMuICBTbyBJ4oCZbSBub3Qgc3VyZSB0
aGF0IEnigJltIHRvdGFsbHkgaW4gYWdyZWVtZW50IHdpdGggWGlhbmcgTGkuICBBIGNyZWF0ZSBv
ZiBhbiBOUCBjb250YWluZXIgY2FuIHJldHVybiBhbiBPSyBidXQgdGhlbiBhIHN1YnNlcXVlbnQg
PGdldC1jb25maWc+IGNhbiBmaWx0ZXIgb3V0IGVtcHR5IE5QIGNvbnRhaW5lcnMuDQoNClJldHVy
bmluZyBOUCBjb250YWluZXJzICh3aGV0aGVyIHRoZXkgd2VyZSBleHBsaWNpdGx5IGNyZWF0ZWQg
b3Igbm90KSBzZWVtcyBsaWtlIGl0IHdvdWxkIHByb2R1Y3QgYSBsb3Qgb2YgdW5uZWNlc3Nhcnkg
bm9pc2UgaW4gYSByZXNwb25zZS4NCg0KUmVnYXJkcywNCkphc29uDQoNCkZyb206IE5ldGNvbmYg
W21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0Bp
ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5
IDE0LCAyMDE2IDEyOjE2DQpUbzogWGlhbmcgTGkNCkNjOiBOZXRjb25mDQpTdWJqZWN0OiBSZTog
W05ldGNvbmZdIFdoYXQgc2hvdWxkIGEgc2VydmVyIHJlc3BvbnNlIGJlPw0KDQpIaSwNCg0KSSBj
YW4gc2VlIHRoZSBjb25mdXNpb24gYmVjYXVzZSBvZiB0aGUgc2xvcHB5IHRleHQgaW4gUkZDIDYy
NDEuDQpOUCBjb250YWluZXJzIGhhdmUgYWx3YXlzIGJlZW4gYSBwcm9ibGVtLiAgVGhlIE5FVE1P
RCBXRyBkaWQgYSBwb29yIGpvYg0Kb2YgZGVmaW5pbmcgdGhlbSBpbiBhbiBpbnRlcm9wZXJhYmxl
IHdheS4NCg0KSU1PIHRoZSBzZXJ2ZXIgc2hvdWxkIG5vdCBkZWxldGUgTlAgY29udGFpbmVycyBm
b3IgZXhhY3RseSB0aGUgY2FzZXMgeW91IHBvaW50IG91dC4NClRoZSBzZXJ2ZXIgZG9lcyBub3Qg
a25vdyB0aGUgY2xpZW50J3MgaW50ZW50aW9ucyBzbyB3aHkgaXMgaXQgZGVsZXRpbmcgbm9kZXM/
DQpBbHNvLCBZQU5HIDEuMSBYUGF0aCBydWxlcyB0cmVhdCBOUCBjb250YWluZXJzIGFzIGlmIHRo
ZXkgYXJlIGFsd2F5cyBwcmVzZW50Lg0KKFNvIHRoZSB0ZXh0IGFib3V0IE1BWSBkZWxldGUgTlAg
Y29udGFpbmVycyBpcyBldmVuIG1vcmUgY29uZnVzaW5nKS4NCg0KDQpBbmR5DQoNCg0KT24gVGh1
LCBKdWwgMTQsIDIwMTYgYXQgOToxMCBBTSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5j
b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KSGksDQoNCk1haGVzaCBhc2tl
ZCBtZSB0byBiZSBtb3JlIHNwZWNpZmljLg0KSWYgdGhlIHNlcnZlciBpcyByZXR1cm5pbmcgPG9r
Lz4gZm9yIGVkaXQgMSBidXQgdGhlIGNhbmRpZGF0ZSBkYXRhc3RvcmUNCmlzIHN0aWxsIGVtcHR5
IGFmdGVyIGVkaXQgMSB0aGVuIHRoaXMgaXMgYSBzZXJ2ZXIgYnVnLg0KDQpBbmR5DQoNCk9uIFdl
ZCwgSnVsIDEzLCAyMDE2IGF0IDI6NTggUE0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3Mu
Y29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90ZToNCkhpLA0KDQpUaGUgaW1wbGVt
ZW50YXRpb24gaGFzIGJ1Z3MuDQpUaGUgUkZDIGlzIGNsZWFyIHdydC8gb3BlcmF0aW9uPW5vbmUg
dnMgbWVyZ2Ugb3IgcmVwbGFjZS4NCg0KDQoNCkFuZHkNCg0KDQpPbiBXZWQsIEp1bCAxMywgMjAx
NiBhdCAyOjU1IFBNLCBYaWFuZyBMaSA8eGlhbmdsaUBzZWd1ZXNvZnQuY29tPG1haWx0bzp4aWFu
Z2xpQHNlZ3Vlc29mdC5jb20+PiB3cm90ZToNCk9uIDcvMTIvMjAxNiA4OjQ1IFBNLCBNYWhlc2gg
SmV0aGFuYW5kYW5pIHdyb3RlOg0KDQpPbiBKdWwgMTIsIDIwMTYsIGF0IDk6MjggQU0sIFhpYW5n
IExpIDx4aWFuZ2xpQHNlZ3Vlc29mdC5jb208bWFpbHRvOnhpYW5nbGlAc2VndWVzb2Z0LmNvbT4+
IHdyb3RlOg0KDQpPbiA3LzExLzIwMTYgMzo0NyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90
ZToNClRoZSBPcGVuZGF5bGlnaHQgY29udHJvbGxlciBpcyBjb25zdHJ1Y3RpbmcgdGhpcyBwYXJ0
aWN1bGFyIHNldCBvZiA8ZWRpdC1jb25maWc+IHJlcXVlc3RzIGFzIHBhcnQgb2YgYSBzaW5nbGUg
dHJhbnNhY3Rpb24uIFRoZSByZXNwb25zZSBvZiB0aGUgc2VydmVyIGlzIHRvIHJlamVjdCB0aGUg
Y29uZmlndXJhdGlvbiB0aGF0IHRoZSBwYXJ0aWN1bGFyIG5vZGUgKGV2cG4gY29udGFpbmVyKSBk
b2VzIG5vdCBleGlzdC4NCg0KSG93ZXZlciwgaWYgdGhlIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUg
aXMgcmVtb3ZlZCBvciBjaGFuZ2VkIHRvIHJlcGxhY2UsIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgd2l0
aCBhbiBSUEMgT0suDQoNCklzIHRoZSBzZXJ2ZXIgcmlnaHQgaW4gaXRzIGludGVycHJldGF0aW9u
IG9mIHdoYXQgUkZDIDYyNDEgc2F5cz8gSW4gcGFydGljdWxhciwgdGhlIHdheSB0aGUgc2VydmVy
IGlzIGludGVycHJldGluZyB0aGlzIHJlcXVlc3QgaXMgYXMgZm9sbG93cyBmcm9tIFNlY3Rpb24g
Ny4yIG9mIHRoZSBSRkM6DQoNCg0KICAgICAgICAgbm9uZTogIFRoZSB0YXJnZXQgZGF0YXN0b3Jl
IGlzIHVuYWZmZWN0ZWQgYnkgdGhlIGNvbmZpZ3VyYXRpb24NCg0KICAgICAgICAgICAgaW4gdGhl
IDxjb25maWc+IHBhcmFtZXRlciwgdW5sZXNzIGFuZCB1bnRpbCB0aGUgaW5jb21pbmcNCg0KICAg
ICAgICAgICAgY29uZmlndXJhdGlvbiBkYXRhIHVzZXMgdGhlICJvcGVyYXRpb24iIGF0dHJpYnV0
ZSB0byByZXF1ZXN0DQoNCiAgICAgICAgICAgIGEgZGlmZmVyZW50IG9wZXJhdGlvbi4gIElmIHRo
ZSBjb25maWd1cmF0aW9uIGluIHRoZSA8Y29uZmlnPg0KDQogICAgICAgICAgICBwYXJhbWV0ZXIg
Y29udGFpbnMgZGF0YSBmb3Igd2hpY2ggdGhlcmUgaXMgbm90IGENCg0KICAgICAgICAgICAgY29y
cmVzcG9uZGluZyBsZXZlbCBpbiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSwgYW4gPHJwYy1lcnJvcj4N
Cg0KICAgICAgICAgICAgaXMgcmV0dXJuZWQgd2l0aCBhbiA8ZXJyb3ItdGFnPiB2YWx1ZSBvZiBk
YXRhLW1pc3NpbmcuDQoNCiAgICAgICAgICAgIFVzaW5nICJub25lIiBhbGxvd3Mgb3BlcmF0aW9u
cyBsaWtlICJkZWxldGUiIHRvIGF2b2lkDQoNCiAgICAgICAgICAgIHVuaW50ZW50aW9uYWxseSBj
cmVhdGluZyB0aGUgcGFyZW50IGhpZXJhcmNoeSBvZiB0aGUgZWxlbWVudA0KDQogICAgICAgICAg
ICB0byBiZSBkZWxldGVkLg0KDQphbmQgdGhlbiB0aGlzOg0KDQoNCiAgICAgIG9wZXJhdGlvbjog
IEVsZW1lbnRzIGluIHRoZSA8Y29uZmlnPiBzdWJ0cmVlIE1BWSBjb250YWluIGFuDQoNCiAgICAg
ICAgICJvcGVyYXRpb24iIGF0dHJpYnV0ZSwgd2hpY2ggYmVsb25ncyB0byB0aGUgTkVUQ09ORiBu
YW1lc3BhY2UNCg0KICAgICAgICAgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMTxodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjNjI0MSNzZWN0aW9uLTMuMT4uICBUaGUgYXR0cmlidXRlIGlkZW50
aWZpZXMgdGhlIHBvaW50IGluDQoNCiAgICAgICAgIHRoZSBjb25maWd1cmF0aW9uIHRvIHBlcmZv
cm0gdGhlIG9wZXJhdGlvbiBhbmQgTUFZIGFwcGVhciBvbg0KDQogICAgICAgICBtdWx0aXBsZSBl
bGVtZW50cyB0aHJvdWdob3V0IHRoZSA8Y29uZmlnPiBzdWJ0cmVlLg0KDQoNCjFzdCByZXF1ZXN0
Og0KDQo8cnBjIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAi
IG1lc3NhZ2UtaWQ9Im0tMjMiPg0KICA8ZWRpdC1jb25maWc+DQogICAgPHRhcmdldD4NCiAgICAg
IDxjYW5kaWRhdGUvPg0KICAgIDwvdGFyZ2V0Pg0KICAgIDxlcnJvci1vcHRpb24+cm9sbGJhY2st
b24tZXJyb3I8L2Vycm9yLW9wdGlvbj4NCiAgICA8Y29uZmlnPg0KICAgICAgPGV2cG4geG1sbnM9
Imh0dHA6Ly9jaXNjby5jb20vbnMveWFuZy9DaXNjby1JT1MtWFItbDJ2cG4tY2ZnIj4NCiAgICAg
ICAgPGV2cG4tdGFibGVzLz4NCiAgICAgIDwvZXZwbj4NCiAgICA8L2NvbmZpZz4NCiAgPC9lZGl0
LWNvbmZpZz4NCjwvcnBjPg0KIyMNCg0KVGhlIGNvbnRhaW5lciBldnBuIGluIHRoaXMgY2FzZSBp
cyBhIG5vbi1wcmVzZW5jZSBjb250YWluZXIgYW5kIGRvZXMgbm90IGNvbnRhaW4gYW55IG1hbmRh
dG9yeSBsZWFmcyBvciBkZWZhdWx0IHN0YXRlbWVudHMuIFRoZSBzZXJ2ZXIgdGhlcmVmb3JlIGlu
dGVycHJldHMgdGhhdCBub3RoaW5nIGhhcyB0byBiZSBkb25lIGhlcmUsIGFzIGl0IGlzIG5vdCBy
ZXF1aXJlZCB0byBjcmVhdGUgYSBlbXB0eSBjb250YWluZXIuDQoNCg0KDQpJIHRoaW5rIHRoZSBj
b250YWluZXIgbm9kZSBuZWVkcyB0byBiZSBjcmVhdGVkIHdoZW4geW91IGFyZSBtZXJnaW5nIHRv
IGNyZWF0ZSBuZXcgbm9kZXMgZXhwbGljaXRseS4NClJGQzYwMjANCjcuNS4gIFRoZSBjb250YWlu
ZXIgU3RhdGVtZW50DQogICA3LjUuOC4gIE5FVENPTkYgPGVkaXQtY29uZmlnPiBPcGVyYXRpb25z
DQoNCiAgICBXaGVuIGEgTkVUQ09ORiBzZXJ2ZXIgcHJvY2Vzc2VzIGFuIDxlZGl0LWNvbmZpZz4g
cmVxdWVzdCwgdGhlDQoNCiAgICBlbGVtZW50cyBvZiBwcm9jZWR1cmUgZm9yIHRoZSBjb250YWlu
ZXIgbm9kZSBhcmU6DQoNCg0KDQogICAgICBJZiB0aGUgb3BlcmF0aW9uIGlzICJtZXJnZSIgb3Ig
InJlcGxhY2UiLCB0aGUgbm9kZSBpcyBjcmVhdGVkIGlmDQoNCiAgICAgIGl0IGRvZXMgbm90IGV4
aXN0Lg0KDQoNCkl0IG1ha2VzIG5vIHNlbnNlIHRvIG1lIGZvciB0aGUgc2VydmVyIHRvIHJldHVy
biBvayBidXQgYWN0dWFsbHkgZG9lcyBub3QgY3JlYXRlIHRoYXQNCmNvbnRhaW5lciBub2RlIGlu
IHRoaXMgY2FzZS4NCg0KQW5kIHRoYXQgaXMgdGhlIGNsYXJpZmljYXRpb24gSSBhbSBzZWVraW5n
LiBOb3RlLCBpdCBpcyBhbiBlbXB0eSBub24tcHJlc2VuY2UgY29udGFpbmVyLiBTaG91bGQgdGhl
IHNlcnZlciBjcmVhdGUgdGhpcyBlbXB0eSBjb250YWluZXIsIGFuZCBpZiBzbyBob3cgd291bGQg
aXQgYmUgcmVwcmVzZW50ZWQgaW4gdGhlIGNvbmZpZyB0cmVlPyBJbiB0aGlzIHBhcnRpY3VsYXIg
Y2FzZSwgdGhlIHJlcXVlc3QgaXMgZm9sbG93ZWQgYnkgY2hpbGQgbm9kZXMuIFdoYXQgaGFwcGVu
cyBpZiBubyBjaGlsZCBub2RlcyBhcmUgY3JlYXRlZD8NCg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlz
IHRoYXQgaXQgZG9lcyBub3QgbWF0dGVyIGlmIGl0IGlzIGEgcHJlc2VuY2UgY29udGFpbmVyIG9y
IG5vdCBpbiB0aGlzIGNhc2UNCiwgbm9yIGlmIHRoZXJlIGFyZSBjaGlsZCBub2RlcyBpbmNsdWRl
ZCAgdG8gYmUgY3JlYXRlZC4NCg0KDQoNCg0KVGhlIHNlcnZlciBtYXkgZGVsZXRlIGFuIGVtcHR5
IGNvbnRhaW5lciBub2RlIGJ1dCBvbmx5IHdoZW4geW91IGRlbGV0aW5nIHN0dWZmOg0KDQoNCklm
IGEgY29udGFpbmVyIGRvZXMgbm90IGhhdmUgYSAicHJlc2VuY2UiIHN0YXRlbWVudCBhbmQgdGhl
IGxhc3QNCg0KICAgY2hpbGQgbm9kZSBpcyBkZWxldGVkLCB0aGUgTkVUQ09ORiBzZXJ2ZXIgTUFZ
IGRlbGV0ZSB0aGUgY29udGFpbmVyLg0KDQpGb3IgYSBkZWxldGUgaXQgaXMgY2xlYXIuIEJ1dCB0
aGUgUkZDIGlzIHNpbGVudCBmb3IgYSBjcmVhdGUgKGFuZCB0aGUgZGVmYXVsdCBvcGVyYXRpb24g
b2YgbWVyZ2UpLg0KDQpJIHRoaW5rIFJGQzYwMjAgNy41LjguICAiTkVUQ09ORiA8ZWRpdC1jb25m
aWc+IE9wZXJhdGlvbnMiIChmb3IgY29udGFpbmVyIG5vZGUpDQpjb3ZlcnMgdGhpcyA6DQoNCi0g
ICAgV2hlbiBhIE5FVENPTkYgc2VydmVyIHByb2Nlc3NlcyBhbiA8ZWRpdC1jb25maWc+IHJlcXVl
c3QsIHRoZQ0KDQotICAgIGVsZW1lbnRzIG9mIHByb2NlZHVyZSBmb3IgdGhlIGNvbnRhaW5lciBu
b2RlIGFyZToNCg0KLQ0KDQotICAgICAgSWYgdGhlIG9wZXJhdGlvbiBpcyAibWVyZ2UiIG9yICJy
ZXBsYWNlIiwgdGhlIG5vZGUgaXMgY3JlYXRlZCBpZg0KDQotICAgICAgaXQgZG9lcyBub3QgZXhp
c3QuDQoNCg0KDQotICAgICAgSWYgdGhlIG9wZXJhdGlvbiBpcyAiY3JlYXRlIiwgdGhlIG5vZGUg
aXMgY3JlYXRlZCBpZiBpdCBkb2VzIG5vdA0KDQotICAgICAgZXhpc3QuICBJZiB0aGUgbm9kZSBh
bHJlYWR5IGV4aXN0cywgYSAiZGF0YS1leGlzdHMiIGVycm9yIGlzDQoNCi0gICAgICByZXR1cm5l
ZC4NCg0KDQpJZiBhIG5vbi1wcmVzZW5jZSBlbXB0eSBjb250YWluZXIgY2FuIGJlIGRlbGV0ZWQs
IHdoeSBzaG91bGQgaXQgYmUgY3JlYXRlZD8NCg0KDQpJdCBpcyBiZWNhdXNlIHRoZSBjbGllbnQg
aXMgc2VuZGluZyBhbiA8ZWRpdC1jb25maWc+ICB0byBjcmVhdGUgdGhpcyBjb250YWluZXIgZXhw
bGljaXRseS4NCklmIGEgY2xpZW50IHdhbnRzIHRvIGNyZWF0ZSAqb25seSogYSBjb250YWluZXIg
bm9kZSwgaXQgY2FuIGNlcnRhaW5seSBkbyBzbyB3aXRob3V0DQpoYXZpbmcgdG8gc3BlY2lmeSBh
bnkgY2hpbGQgaW5zdGFuY2Ugbm9kZXMuIElmIHRoZSBzZXJ2ZXIgcmV0dXJucyAiT2siIGZvciBz
dWNoDQphIHJlcXVlc3QgdGhlbiBpdCBtdXN0IG1lYW4gaXQgaGFzIGluZGVlZCBjcmVhdGVkIHRo
ZSBjb250YWluZXIgbm9kZS4NCg0KSSB0aGluayBpdCBtYWtlcyBsaXR0bGUgc2Vuc2UgZm9yIGEg
c2VydmVyIHRvIHJldHVybiAiT2siIGJ1dCBkb2VzIG5vdCBjcmVhdGUNCnRoZSBjb250YWluZXIg
bm9kZSAodGhpbmtpbmcgbm90aGluZyBuZWVkcyB0byBiZSBkb25lIGlmIHRoZXJlIGFyZSBubyBj
aGlsZCBub2Rlcw0KaW5jbHVkZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCkuIFRoZSAiT2siIHJlc3Bv
bnNlIG11c3QgbWVhbiBzb21ldGhpbmcsIGkuZS4sDQp0aGUgY3JlYXRlL21lcmdlL3JlcGxhY2Ug
b3BlcmF0aW9ucyBoYXMgYWN0dWFsbHkgc3VjY2VlZGVkIGluIGNyZWF0aW5nIHRoZQ0KY29udGFp
bmVyIG5vZGUgaW4gcXVlc3Rpb24uDQoNCi1YaWFuZw0KDQoNClRoYW5rcy4NCg0KDQoybmQgcmVx
dWVzdDoNCg0KPHJwYyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6
MS4wIiBtZXNzYWdlLWlkPSJtLTI0Ij4NCiAgPGVkaXQtY29uZmlnPg0KICAgIDx0YXJnZXQ+DQog
ICAgICA8Y2FuZGlkYXRlLz4NCiAgICA8L3RhcmdldD4NCiAgICA8ZGVmYXVsdC1vcGVyYXRpb24+
bm9uZTwvZGVmYXVsdC1vcGVyYXRpb24+DQogICAgPGVycm9yLW9wdGlvbj5yb2xsYmFjay1vbi1l
cnJvcjwvZXJyb3Itb3B0aW9uPg0KICAgIDxjb25maWc+DQogICAgICA8ZXZwbiB4bWxucz0iaHR0
cDovL2Npc2NvLmNvbS9ucy95YW5nL0Npc2NvLUlPUy1YUi1sMnZwbi1jZmciPg0KICAgICAgICA8
ZXZwbi10YWJsZXM+DQogICAgICAgICAgPGV2cG4tbG9hZC1iYWxhbmNpbmcgeG1sbnM6YT0idXJu
OmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiBhOm9wZXJhdGlvbj0icmVwbGFj
ZSI+DQogICAgICAgICAgICA8ZW5hYmxlLz4NCiAgICAgICAgICAgIDxldnBuLWZsb3ctbGFiZWwv
Pg0KICAgICAgICAgIDwvZXZwbi1sb2FkLWJhbGFuY2luZz4NCiAgICAgICAgPC9ldnBuLXRhYmxl
cz4NCiAgICAgIDwvZXZwbj4NCiAgICA8L2NvbmZpZz4NCiAgPC9lZGl0LWNvbmZpZz4NCjwvcnBj
Pg0KIyMNCg0KSW4gdGhlIHNlY29uZCByZXF1ZXN0LCB0aGUgZGVmYXVsdC1vcGVyYXRpb249bm9u
ZSBhZ2FpbiBzZWVtcyB0byBpbXBseSB0aGF0IG5vdGhpbmcgbmVlZHMgdG8gYmUgZG9uZSBmb3Ig
Y3JlYXRpb24gb2YgdGhlIGV2cG4gbm9kZS4gVGhlcmVmb3JlIGJ5IHRoZSB0aW1lIHRoZSBldnBu
LWxvYWQtYmFsYW5jaW5nIHJlcXVlc3Qgcm9sbHMgYXJvdW5kLCB0aGUgcmVxdWVzdCBpcyByZWpl
Y3RlZCBhcyB0aGUgcGFyZW50IGNvbnRhaW5lciBkb2VzIG5vdCBleGlzdC4gQXMgc3RhdGVkIGVh
cmxpZXIsIGlmIHRoZSBkZWZhdWx0LW9wZXJhdGlvbiBpcyByZW1vdmVkIChjYXVzaW5nIGEgZGVm
YXVsdCBvZiBtZXJnZSkgb3IgcmVwbGFjZWQgd2l0aCBhIHJlcGxhY2UsIHRoZSB0cmFuc2FjdGlv
biBzdWNjZWVkcy4NCg0KQSBzZWNvbmQgaW50ZXJwcmV0YXRpb24gdG8gdGhpcyB0cmFuc2FjdGlv
biBpcyB0aGF0IHRoZSBzZXJ2ZXIgc2hvdWxkIGhhdmUgY3JlYXRlZCB0aGUgZXZwbiBub2RlIGFz
IHBhcnQgb2YgdGhlIGZpcnN0IHJlcXVlc3QsIGFuZCB0aGF0IHRoZSBub25lIG9wZXJhdGlvbiB3
YXMgaW1wbHlpbmcgdGhhdCB0aGUgbm9kZSBoYWQgYWxyZWFkeSBiZWVuIGNyZWF0ZWQuDQoNCg0K
DQpJZiB0aGUgc2VydmVyIHJldHVybnMgb2sgZm9yIHRoZSBmaXJzdCA8ZWRpdC1jb25maWc+LCB0
aGVuIGl0IG1lYW5zIGl0IGhhcyBzdWNjZXNzZnVsbHkgY3JlYXRlZCB0aGUgdG9wIHR3byBjb250
YWluZXIgbm9kZXMgaW4gdGhlIGhpZXJhcmNoeToNCiAgICAgIDxldnBuID4NCiAgICAgICAgPGV2
cG4tdGFibGVzPg0KDQp0aGVuIHRoZSBzZWNvbmQgcmVxdWVzdCBzaG91bGQgaGF2ZSBzdWNjZWVk
ZWQuDQoNCg0KLVhpYW5nIExpDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlA
Z21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGlu
ZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0KDQoNCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCC9C5DUS70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw
YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N
CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD
aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm
b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6
IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgSSBkb27igJl0IHJl
YWxseSBzZWUgTlAtY29udGFpbmVycyBhcyDigJxjb25maWfigJ0uJm5ic3A7IFRoZXkgYXJlIGp1
c3Qgc3RydWN0dXJlIGFuZCBmaWx0ZXJlZCBvdXQgd2hlbiBlbXB0eS4mbmJzcDsgSSBkb27igJl0
IHJlYWxseSBzZWUgdGhpcyBhcyB0aGUgc2VydmVyIOKAnGRlbGV0aW5n4oCdDQogdGhvc2UgY29u
dGFpbmVycy4mbmJzcDsgSXQganVzdCBzdXBwcmVzc2VzIHRoZW0gaW4gJmx0O2dldC1jb25maWcm
Z3Q7IG91dHB1dC4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgc2VydmVyIHNob3VsZCBub3Qg
ZXJyb3IgaW4gdGhlIGNhc2VzIE1haGVzaCAmYW1wOyBFaW5hciBzaG93IC0mZ3Q7IHRoZSBwcmVz
ZW5jZS9leGlzdGVuY2Ugb2YgTlAtY29udGFpbmVycyBzaG91bGRu4oCZdCByZWFsbHkgYWZmZWN0
IGJlaGF2aW9yIChzaW5jZSB0aGV5IGFyZW7igJl0DQogcmVhbGx5IGNvbmZpZykuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5CdXQgSeKAmW0gbm90IHBvc2l0aXZlIHdoYXQgeW91IG1lYW4gYnkg4oCcbWFuYWdlciBuZWVk
cyB0byBndWFyZOKAnS4mbmJzcDsgRG8geW91IGFncmVlIHRoYXQgdGhlIHNlcnZlciBzaG91bGQg
bm90IGVycm9yIGluIHRob3NlIGNhc2VzIGJlbG93ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphc29uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5T
ZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTQsIDIwMTYgMTU6MDE8YnI+DQo8Yj5Ubzo8L2I+IFN0
ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpPGJyPg0KPGI+Q2M6PC9iPiBYaWFuZyBMaTsgTmV0Y29u
Zjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFdoYXQgc2hvdWxkIGEgc2VydmVy
IHJlc3BvbnNlIGJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg
cHJvYmxlbSBpcyB0aGlzIGhvcnJpYmxlIHRleHQgaW4gdGhlIFlBTkcgUkZDOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJpcy0xNCNz
ZWN0aW9uLTcuNS44Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRt
b2QtcmZjNjAyMGJpcy0xNCNzZWN0aW9uLTcuNS44PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElm
IGEgY29udGFpbmVyIGRvZXMgbm90IGhhdmUgYSAmcXVvdDtwcmVzZW5jZSZxdW90OyBzdGF0ZW1l
bnQgYW5kIHRoZSBsYXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNoaWxkIG5vZGUgaXMgZGVsZXRlZCwgdGhlIE5F
VENPTkYgc2VydmVyIE1BWSBkZWxldGUgdGhlIGNvbnRhaW5lci48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBnb29kIGV4YW1wbGUg
b2Ygd2h5IGlzIGEgYmFkIGlkZWEgdG8gZGVmaW5lIE5FVENPTkYgcHJvdG9jb2wgZGV0YWlsczxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gdGhl
IFlBTkcgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+TkVUQ09ORiBpdHNlbGYgbmV2ZXIgc2F5cyBpdCBpcyBPSyBmb3IgdGhlIHNlcnZl
ciB0byBkZWxldGUgZWRpdHMgZnJvbSB0aGUgY2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFRoaXMgaXMgZXNwZWNpYWxseSBkdW1iIGlu
IHRoZSBjYW5kaWRhdGUgY29uZmlnIGJlY2F1c2UgaXRzIHNvbGUgcHVycG9zZSBpczxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gYmUgYSBzY3Jh
dGNocGFkIGZvciBpbmNyZW1lbnRhbCBlZGl0cyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSBoYXZlIHRvIHNheSB0byBzZXJ2ZXIgaXMg
YWxsb3dlZCB0byBkZWxldGUgdGhlIGVtcHR5IE5QIGNvbnRhaW5lcnMsPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhlIG1hbmFnZXIgbmVl
ZHMgdG8gZ3VhcmQgYWdhaW5zdCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIHRoYXQgZGVsZXRlPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lbXB0eSBO
UCBjb250YWluZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGlzIHNvcnQgb2YgdmFyaWFiaWxpdHkgd2l0aG91dCBwdXJwb3NlIGhhcm1z
IGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDE0LCAyMDE2IGF0IDExOjQ3
IEFNLCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29u
LnN0ZXJuZUBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5qYXNvbi5zdGVybmVAbm9raWEuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklN
TyB0aG9zZSBleGFtcGxlcyBmcm9tIE1haGVzaCBhbmQgRWluYXIgc2hvdWxkIGFsbCBzdWNjZWVk
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkJ1dCBhZnRlciB0aGUgMTxzdXA+c3Q8L3N1cD4gcmVxdWVzdCBJIGRv
buKAmXQgdGhpbmsgYSAmbHQ7Z2V0LWNvbmZpZyZndDsgaXMgcmVxdWlyZWQgdG8gcmV0dXJuIGFu
eSBlbXB0eQ0KIE5QIGNvbnRhaW5lcnMuJm5ic3A7IFNvIEnigJltIG5vdCBzdXJlIHRoYXQgSeKA
mW0gdG90YWxseSBpbiBhZ3JlZW1lbnQgd2l0aCBYaWFuZyBMaS4mbmJzcDsgQSBjcmVhdGUgb2Yg
YW4gTlAgY29udGFpbmVyIGNhbiByZXR1cm4gYW4gT0sgYnV0IHRoZW4gYSBzdWJzZXF1ZW50ICZs
dDtnZXQtY29uZmlnJmd0OyBjYW4gZmlsdGVyIG91dCBlbXB0eSBOUCBjb250YWluZXJzLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlJldHVybmluZyBOUCBjb250YWluZXJzICh3aGV0aGVyIHRoZXkgd2VyZSBleHBs
aWNpdGx5IGNyZWF0ZWQgb3Igbm90KSBzZWVtcyBsaWtlIGl0IHdvdWxkIHByb2R1Y3QNCiBhIGxv
dCBvZiB1bm5lY2Vzc2FyeSBub2lzZSBpbiBhIHJlc3BvbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy
ZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFzb248L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiBOZXRjb25mIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVs
eSAxNCwgMjAxNiAxMjoxNjxicj4NCjxiPlRvOjwvYj4gWGlhbmcgTGk8YnI+DQo8Yj5DYzo8L2I+
IE5ldGNvbmY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBXaGF0IHNob3VsZCBh
IHNlcnZlciByZXNwb25zZSBiZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5JIGNhbiBzZWUgdGhlIGNvbmZ1c2lvbiBiZWNhdXNlIG9mIHRoZSBzbG9wcHkg
dGV4dCBpbiBSRkMgNjI0MS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+TlAgY29udGFpbmVycyBoYXZlIGFsd2F5cyBiZWVuIGEgcHJvYmxlbS4m
bmJzcDsgVGhlIE5FVE1PRCBXRyBkaWQgYSBwb29yIGpvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vZiBkZWZpbmluZyB0aGVtIGluIGFuIGlu
dGVyb3BlcmFibGUgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SU1PIHRoZSBzZXJ2ZXIgc2hvdWxkIG5vdCBkZWxldGUgTlAgY29u
dGFpbmVycyBmb3IgZXhhY3RseSB0aGUgY2FzZXMgeW91IHBvaW50IG91dC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHNlcnZlciBkb2Vz
IG5vdCBrbm93IHRoZSBjbGllbnQncyBpbnRlbnRpb25zIHNvIHdoeSBpcyBpdCBkZWxldGluZyBu
b2Rlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+QWxzbywgWUFORyAxLjEgWFBhdGggcnVsZXMgdHJlYXQgTlAgY29udGFpbmVycyBhcyBpZiB0
aGV5IGFyZSBhbHdheXMgcHJlc2VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+KFNvIHRoZSB0ZXh0IGFib3V0IE1BWSBkZWxldGUgTlAgY29u
dGFpbmVycyBpcyBldmVuIG1vcmUgY29uZnVzaW5nKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBK
dWwgMTQsIDIwMTYgYXQgOToxMCBBTSwgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86
YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5N
YWhlc2ggYXNrZWQgbWUgdG8gYmUgbW9yZSBzcGVjaWZpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhlIHNlcnZlciBpcyByZXR1cm5p
bmcgJmx0O29rLyZndDsgZm9yIGVkaXQgMSBidXQgdGhlIGNhbmRpZGF0ZSBkYXRhc3RvcmU8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aXMgc3Rp
bGwgZW1wdHkgYWZ0ZXIgZWRpdCAxIHRoZW4gdGhpcyBpcyBhIHNlcnZlciBidWcuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBK
dWwgMTMsIDIwMTYgYXQgMjo1OCBQTSwgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86
YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U
aGUgaW1wbGVtZW50YXRpb24gaGFzIGJ1Z3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBSRkMgaXMgY2xlYXIgd3J0LyBvcGVyYXRpb249
bm9uZSB2cyBtZXJnZSBvciByZXBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKdWwg
MTMsIDIwMTYgYXQgMjo1NSBQTSwgWGlhbmcgTGkgJmx0OzxhIGhyZWY9Im1haWx0bzp4aWFuZ2xp
QHNlZ3Vlc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj54aWFuZ2xpQHNlZ3Vlc29mdC5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5PbiA3LzEyLzIwMTYgODo0NSBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g
SnVsIDEyLCAyMDE2LCBhdCA5OjI4IEFNLCBYaWFuZyBMaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnhp
YW5nbGlAc2VndWVzb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnhpYW5nbGlAc2VndWVzb2Z0LmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5PbiA3LzExLzIwMTYgMzo0NyBQTSwgTWFoZXNoIEpldGhhbmFuZGFu
aSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5UaGUgT3BlbmRheWxpZ2h0IGNvbnRyb2xsZXIgaXMgY29uc3RydWN0aW5nIHRoaXMg
cGFydGljdWxhciBzZXQgb2YgJmx0O2VkaXQtY29uZmlnJmd0OyByZXF1ZXN0cyBhcyBwYXJ0IG9m
IGEgc2luZ2xlIHRyYW5zYWN0aW9uLiBUaGUgcmVzcG9uc2Ugb2YgdGhlIHNlcnZlciBpcyB0byBy
ZWplY3QgdGhlIGNvbmZpZ3VyYXRpb24NCiB0aGF0IHRoZSBwYXJ0aWN1bGFyIG5vZGUgKGV2cG4g
Y29udGFpbmVyKSBkb2VzIG5vdCBleGlzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhvd2V2ZXIsIGlmIHRoZSBkZWZhdWx0
LW9wZXJhdGlvbj1ub25lIGlzIHJlbW92ZWQgb3IgY2hhbmdlZCB0byByZXBsYWNlLCB0aGUgc2Vy
dmVyIHJlc3BvbmRzIHdpdGggYW4gUlBDIE9LLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXMgdGhlIHNlcnZlciByaWdodCBpbiBpdHMg
aW50ZXJwcmV0YXRpb24gb2Ygd2hhdCBSRkMgNjI0MSBzYXlzPyBJbiBwYXJ0aWN1bGFyLCB0aGUg
d2F5IHRoZSBzZXJ2ZXIgaXMgaW50ZXJwcmV0aW5nIHRoaXMgcmVxdWVzdCBpcyBhcyBmb2xsb3dz
IGZyb20gU2VjdGlvbiA3LjIgb2YgdGhlIFJGQzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBub25lOiZuYnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6I0I1MUEwMCI+VGhlIHRhcmdldCBk
YXRhc3RvcmUgaXMgdW5hZmZlY3RlZCBieSB0aGUgY29uZmlndXJhdGlvbjwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0I1MUEwMCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlu
IHRoZSAmbHQ7Y29uZmlnJmd0OyBwYXJhbWV0ZXIsIHVubGVzcyBhbmQgdW50aWwgdGhlIGluY29t
aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojQjUx
QTAwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbiBkYXRhIHVzZXMgdGhlICZxdW90O29wZXJhdGlv
biZxdW90OyBhdHRyaWJ1dGUgdG8gcmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6I0I1MUEwMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgZGlmZmVyZW50IG9wZXJh
dGlvbi4gPC9zcGFuPiZuYnNwO0lmIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSAmbHQ7Y29uZmln
Jmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIgY29udGFpbnMg
ZGF0YSBmb3Igd2hpY2ggdGhlcmUgaXMgbm90IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgY29ycmVzcG9uZGluZyBsZXZlbCBpbiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSwgYW4gJmx0
O3JwYy1lcnJvciZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgcmV0dXJu
ZWQgd2l0aCBhbiAmbHQ7ZXJyb3ItdGFnJmd0OyB2YWx1ZSBvZiBkYXRhLW1pc3NpbmcuPG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVzaW5nICZxdW90O25vbmUmcXVvdDsgYWxsb3dz
IG9wZXJhdGlvbnMgbGlrZSAmcXVvdDtkZWxldGUmcXVvdDsgdG8gYXZvaWQ8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgdW5pbnRlbnRpb25hbGx5IGNyZWF0aW5nIHRoZSBwYXJlbnQg
aGllcmFyY2h5IG9mIHRoZSBlbGVtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw
O3RvIGJlIGRlbGV0ZWQuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPmFuZCB0aGVuIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BlcmF0aW9u
OiZuYnNwOyBFbGVtZW50cyBpbiB0aGUgJmx0O2NvbmZpZyZndDsgc3VidHJlZSBNQVkgY29udGFp
biBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtvcGVyYXRpb24mcXVvdDsgYXR0cmlidXRlLCB3aGlj
aCBiZWxvbmdzIHRvIHRoZSBORVRDT05GIG5hbWVzcGFjZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVk
IGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQxI3NlY3Rpb24t
My4xIiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlvbiAzLjE8L2E+LiZuYnNwOyA8c3BhbiBzdHlsZT0i
Y29sb3I6I0I1MUEwMCI+VGhlIGF0dHJpYnV0ZSBpZGVudGlmaWVzIHRoZSBwb2ludCBpbjwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0I1MUEwMCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBjb25maWd1
cmF0aW9uIHRvIHBlcmZvcm0gdGhlIG9wZXJhdGlvbiBhbmQgTUFZIGFwcGVhciBvbjwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0I1MUEwMCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIGVsZW1l
bnRzIHRocm91Z2hvdXQgdGhlICZsdDtjb25maWcmZ3Q7IHN1YnRyZWUuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xPHN1cD5zdDwvc3Vw
PiZuYnNwO3JlcXVlc3Q6PC9zcGFuPjwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbHQ7cnBjIHhtbG5z
PSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyBtZXNz
YWdlLWlkPSZxdW90O20tMjMmcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Jm5ic3A7ICZsdDtlZGl0LWNvbmZpZyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3RhcmdldCZndDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0
O2NhbmRpZGF0ZS8mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICZsdDsvdGFyZ2V0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZXJyb3Itb3B0aW9uJmd0O3JvbGxiYWNrLW9u
LWVycm9yJmx0Oy9lcnJvci1vcHRpb24mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtjb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtldnBu
IHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9jaXNjby5jb20vbnMveWFuZy9DaXNjby1JT1Mt
WFItbDJ2cG4tY2ZnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2Npc2NvLmNvbS9ucy95YW5nL0Np
c2NvLUlPUy1YUi1sMnZwbi1jZmc8L2E+JnF1b3Q7Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
bHQ7ZXZwbi10YWJsZXMvJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2V2cG4mZ3Q7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvY29uZmlnJmd0Ozwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAmbHQ7L2VkaXQtY29uZmln
Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZsdDsvcnBjJmd0Ozwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiMjPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY29udGFpbmVyIGV2cG4gaW4gdGhpcyBjYXNlIGlz
IGEgbm9uLXByZXNlbmNlIGNvbnRhaW5lciBhbmQgZG9lcyBub3QgY29udGFpbiBhbnkgbWFuZGF0
b3J5IGxlYWZzIG9yIGRlZmF1bHQgc3RhdGVtZW50cy4gVGhlIHNlcnZlciB0aGVyZWZvcmUgaW50
ZXJwcmV0cyB0aGF0IG5vdGhpbmcgaGFzIHRvIGJlDQogZG9uZSBoZXJlLCBhcyBpdCBpcyBub3Qg
cmVxdWlyZWQgdG8gY3JlYXRlIGEgZW1wdHkgY29udGFpbmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KSSB0aGluayB0aGUgY29u
dGFpbmVyIG5vZGUgbmVlZHMgdG8gYmUgY3JlYXRlZCB3aGVuIHlvdSBhcmUgbWVyZ2luZyB0byBj
cmVhdGUgbmV3IG5vZGVzIGV4cGxpY2l0bHkuPGJyPg0KUkZDNjAyMCA8YnI+DQo3LjUuJm5ic3A7
IFRoZSBjb250YWluZXIgU3RhdGVtZW50PGJyPg0KJm5ic3A7Jm5ic3A7IDcuNS44LiZuYnNwOyBO
RVRDT05GICZsdDtlZGl0LWNvbmZpZyZndDsgT3BlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHBy
ZT4mbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiBhIE5FVENPTkYgc2VydmVyIHByb2Nlc3NlcyBhbiAm
bHQ7ZWRpdC1jb25maWcmZ3Q7IHJlcXVlc3QsIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyZuYnNwOyBlbGVtZW50cyBvZiBwcm9jZWR1cmUgZm9yIHRoZSBjb250YWluZXIg
bm9kZSBhcmU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoZSBvcGVyYXRpb24gaXMg
JnF1b3Q7bWVyZ2UmcXVvdDsgb3IgJnF1b3Q7cmVwbGFjZSZxdW90OywgdGhlIG5vZGUgaXMgY3Jl
YXRlZCBpZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBpdCBkb2VzIG5vdCBleGlzdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBtYWtlcyBubyBzZW5zZSB0
byBtZSBmb3IgdGhlIHNlcnZlciB0byByZXR1cm4gb2sgYnV0IGFjdHVhbGx5IGRvZXMgbm90IGNy
ZWF0ZSB0aGF0PGJyPg0KY29udGFpbmVyIG5vZGUgaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkFuZCB0aGF0IGlzIHRoZSBjbGFyaWZpY2F0aW9uIEkgYW0gc2Vla2luZy4gTm90ZSwgaXQg
aXMgYW4gZW1wdHkgbm9uLXByZXNlbmNlIGNvbnRhaW5lci4gU2hvdWxkIHRoZSBzZXJ2ZXIgY3Jl
YXRlIHRoaXMgZW1wdHkgY29udGFpbmVyLCBhbmQgaWYgc28gaG93IHdvdWxkIGl0IGJlIHJlcHJl
c2VudGVkIGluDQogdGhlIGNvbmZpZyB0cmVlPyBJbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgdGhl
IHJlcXVlc3QgaXMgZm9sbG93ZWQgYnkgY2hpbGQgbm9kZXMuIFdoYXQgaGFwcGVucyBpZiBubyBj
aGlsZCBub2RlcyBhcmUgY3JlYXRlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0
IGl0IGRvZXMgbm90IG1hdHRlciBpZiBpdCBpcyBhIHByZXNlbmNlIGNvbnRhaW5lciBvciBub3Qg
aW4gdGhpcyBjYXNlPGJyPg0KLCBub3IgaWYgdGhlcmUgYXJlIGNoaWxkIG5vZGVzIGluY2x1ZGVk
Jm5ic3A7IHRvIGJlIGNyZWF0ZWQuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KVGhlIHNl
cnZlciBtYXkgZGVsZXRlIGFuIGVtcHR5IGNvbnRhaW5lciBub2RlIGJ1dCBvbmx5IHdoZW4geW91
IGRlbGV0aW5nIHN0dWZmOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5JZiBhIGNv
bnRhaW5lciBkb2VzIG5vdCBoYXZlIGEgJnF1b3Q7cHJlc2VuY2UmcXVvdDsgc3RhdGVtZW50IGFu
ZCB0aGUgbGFzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjaGlsZCBub2Rl
IGlzIGRlbGV0ZWQsIHRoZSBORVRDT05GIHNlcnZlciBNQVkgZGVsZXRlIHRoZSBjb250YWluZXIu
PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgYSBkZWxldGUgaXQgaXMgY2xlYXIuIEJ1dCB0aGUgUkZD
IGlzIHNpbGVudCBmb3IgYSBjcmVhdGUgKGFuZCB0aGUgZGVmYXVsdCBvcGVyYXRpb24gb2YgbWVy
Z2UpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N
CkkgdGhpbmsgUkZDNjAyMCA3LjUuOC4mbmJzcDsgJnF1b3Q7TkVUQ09ORiAmbHQ7ZWRpdC1jb25m
aWcmZ3Q7IE9wZXJhdGlvbnMmcXVvdDsgKGZvciBjb250YWluZXIgbm9kZSk8YnI+DQpjb3ZlcnMg
dGhpcyA6IDxvOnA+PC9vOnA+PC9wPg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gYSBO
RVRDT05GIHNlcnZlciBwcm9jZXNzZXMgYW4gJmx0O2VkaXQtY29uZmlnJmd0OyByZXF1ZXN0LCB0
aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7IGVsZW1lbnRzIG9m
IHByb2NlZHVyZSBmb3IgdGhlIGNvbnRhaW5lciBub2RlIGFyZTo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4tPG86cD48L286cD48L3ByZT4NCjxwcmU+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBJZiB0aGUgb3BlcmF0aW9uIGlzICZxdW90O21lcmdlJnF1b3Q7IG9yICZxdW90O3JlcGxh
Y2UmcXVvdDssIHRoZSBub2RlIGlzIGNyZWF0ZWQgaWY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4t
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IGRvZXMgbm90IGV4aXN0LjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoZSBvcGVyYXRpb24g
aXMgJnF1b3Q7Y3JlYXRlJnF1b3Q7LCB0aGUgbm9kZSBpcyBjcmVhdGVkIGlmIGl0IGRvZXMgbm90
PG86cD48L286cD48L3ByZT4NCjxwcmU+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl
eGlzdC4mbmJzcDsgSWYgdGhlIG5vZGUgYWxyZWFkeSBleGlzdHMsIGEgJnF1b3Q7ZGF0YS1leGlz
dHMmcXVvdDsgZXJyb3IgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHJldHVybmVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SWYgYSBub24tcHJlc2VuY2UgZW1wdHkgY29udGFpbmVyIGNhbiBiZSBkZWxldGVkLCB3
aHkgc2hvdWxkIGl0IGJlIGNyZWF0ZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t
OjEyLjBwdCI+PGJyPg0KPGJyPg0KSXQgaXMgYmVjYXVzZSB0aGUgY2xpZW50IGlzIHNlbmRpbmcg
YW4gJmx0O2VkaXQtY29uZmlnJmd0OyZuYnNwOyB0byBjcmVhdGUgdGhpcyBjb250YWluZXIgZXhw
bGljaXRseS48YnI+DQpJZiBhIGNsaWVudCB3YW50cyB0byBjcmVhdGUgKm9ubHkqIGEgY29udGFp
bmVyIG5vZGUsIGl0IGNhbiBjZXJ0YWlubHkgZG8gc28gd2l0aG91dA0KPGJyPg0KaGF2aW5nIHRv
IHNwZWNpZnkgYW55IGNoaWxkIGluc3RhbmNlIG5vZGVzLiBJZiB0aGUgc2VydmVyIHJldHVybnMg
JnF1b3Q7T2smcXVvdDsgZm9yIHN1Y2g8YnI+DQphIHJlcXVlc3QgdGhlbiBpdCBtdXN0IG1lYW4g
aXQgaGFzIGluZGVlZCBjcmVhdGVkIHRoZSBjb250YWluZXIgbm9kZS48YnI+DQo8YnI+DQpJIHRo
aW5rIGl0IG1ha2VzIGxpdHRsZSBzZW5zZSBmb3IgYSBzZXJ2ZXIgdG8gcmV0dXJuICZxdW90O09r
JnF1b3Q7IGJ1dCBkb2VzIG5vdCBjcmVhdGUgPGJyPg0KdGhlIGNvbnRhaW5lciBub2RlICh0aGlu
a2luZyBub3RoaW5nIG5lZWRzIHRvIGJlIGRvbmUgaWYgdGhlcmUgYXJlIG5vIGNoaWxkIG5vZGVz
PGJyPg0KaW5jbHVkZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCkuIFRoZSAmcXVvdDtPayZxdW90OyBy
ZXNwb25zZSBtdXN0IG1lYW4gc29tZXRoaW5nLCBpLmUuLDxicj4NCnRoZSBjcmVhdGUvbWVyZ2Uv
cmVwbGFjZSBvcGVyYXRpb25zIGhhcyBhY3R1YWxseSBzdWNjZWVkZWQgaW4gY3JlYXRpbmcgdGhl
IDxicj4NCmNvbnRhaW5lciBub2RlIGluIHF1ZXN0aW9uLjxicj4NCjxicj4NCi1YaWFuZzxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjI8c3VwPm5kPC9zdXA+Jm5ic3A7
cmVxdWVzdDo8L3NwYW4+PC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZsdDtycGMgeG1sbnM9JnF1b3Q7
dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7IG1lc3NhZ2UtaWQ9
JnF1b3Q7bS0yNCZxdW90OyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m
bmJzcDsgJmx0O2VkaXQtY29uZmlnJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dGFyZ2V0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2FuZGlk
YXRlLyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsgJmx0Oy90YXJnZXQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj
b2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZGVmYXVsdC1vcGVyYXRpb24mZ3Q7bm9u
ZSZsdDsvZGVmYXVsdC1vcGVyYXRpb24mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtlcnJvci1vcHRpb24mZ3Q7cm9sbGJhY2stb24t
ZXJyb3ImbHQ7L2Vycm9yLW9wdGlvbiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2NvbmZpZyZndDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2V2cG4g
eG1sbnM9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2Npc2NvLmNvbS9ucy95YW5nL0Npc2NvLUlPUy1Y
Ui1sMnZwbi1jZmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vY2lzY28uY29tL25zL3lhbmcvQ2lz
Y28tSU9TLVhSLWwydnBuLWNmZzwvYT4mcXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs
dDtldnBuLXRhYmxlcyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2V2
cG4tbG9hZC1iYWxhbmNpbmcgeG1sbnM6YT0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5l
dGNvbmY6YmFzZToxLjAmcXVvdDsgYTpvcGVyYXRpb249JnF1b3Q7cmVwbGFjZSZxdW90OyZndDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2VuYWJsZS8m
Z3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtldnBu
LWZsb3ctbGFiZWwvJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2V2
cG4tbG9hZC1iYWxhbmNpbmcmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvZXZwbi10YWJs
ZXMmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZsdDsvZXZwbiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9jb25maWcmZ3Q7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ICZsdDsvZWRpdC1jb25maWcmZ3Q7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jmx0Oy9ycGMmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+IyM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhlIHNlY29uZCByZXF1ZXN0LCB0aGUgZGVmYXVsdC1v
cGVyYXRpb249bm9uZSBhZ2FpbiBzZWVtcyB0byBpbXBseSB0aGF0IG5vdGhpbmcgbmVlZHMgdG8g
YmUgZG9uZSBmb3IgY3JlYXRpb24gb2YgdGhlIGV2cG4gbm9kZS4gVGhlcmVmb3JlIGJ5IHRoZSB0
aW1lIHRoZSBldnBuLWxvYWQtYmFsYW5jaW5nDQogcmVxdWVzdCByb2xscyBhcm91bmQsIHRoZSBy
ZXF1ZXN0IGlzIHJlamVjdGVkIGFzIHRoZSBwYXJlbnQgY29udGFpbmVyIGRvZXMgbm90IGV4aXN0
LiBBcyBzdGF0ZWQgZWFybGllciwgaWYgdGhlIGRlZmF1bHQtb3BlcmF0aW9uIGlzIHJlbW92ZWQg
KGNhdXNpbmcgYSBkZWZhdWx0IG9mIG1lcmdlKSBvciByZXBsYWNlZCB3aXRoIGEgcmVwbGFjZSwg
dGhlIHRyYW5zYWN0aW9uIHN1Y2NlZWRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QSBzZWNvbmQgaW50ZXJwcmV0YXRpb24gdG8gdGhp
cyB0cmFuc2FjdGlvbiBpcyB0aGF0IHRoZSBzZXJ2ZXIgc2hvdWxkIGhhdmUgY3JlYXRlZCB0aGUg
ZXZwbiBub2RlIGFzIHBhcnQgb2YgdGhlIGZpcnN0IHJlcXVlc3QsIGFuZCB0aGF0IHRoZSBub25l
IG9wZXJhdGlvbiB3YXMgaW1wbHlpbmcgdGhhdCB0aGUNCiBub2RlIGhhZCBhbHJlYWR5IGJlZW4g
Y3JlYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxicj4NCjxicj4NCklmIHRoZSBzZXJ2ZXIgcmV0dXJucyBvayBmb3IgdGhl
IGZpcnN0ICZsdDtlZGl0LWNvbmZpZyZndDssIHRoZW4gaXQgbWVhbnMgaXQgaGFzIHN1Y2Nlc3Nm
dWxseSBjcmVhdGVkIHRoZSB0b3AgdHdvIGNvbnRhaW5lciBub2RlcyBpbiB0aGUgaGllcmFyY2h5
OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7
ZXZwbiAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2V2cG4tdGFibGVzJmd0Ozxicj4NCjxicj4NCnRo
ZW4gdGhlIHNlY29uZCByZXF1ZXN0IHNob3VsZCBoYXZlIHN1Y2NlZWRlZC48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGJyPg0KPGJyPg0KLVhpYW5nIExpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1haGVzaCBK
ZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9
Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86TmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk5ldGNvbmZAaWV0Zi5vcmc8
L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCC9C5DUS70TWXCHMBA11z_--


From nobody Thu Jul 14 12:13:48 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFED212D1EA for ; Thu, 14 Jul 2016 12:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xPZEI2BZeCh for ; Thu, 14 Jul 2016 12:13:43 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF31212D1D7 for ; Thu, 14 Jul 2016 12:13:42 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id x130so125233792vkc.0 for ; Thu, 14 Jul 2016 12:13:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ro6Rk72CzPJwh4AjD/NBIy/hGV6lYup9gMAuA/sY2pk=; b=g/yWWYYuKxbtN12avbRfBFnBUm67gtSaqIYwZ8ubVJEIUOtYtqFzCO5eDIxRMCgFKS r9Tx1Rat7HqDCA+2zUHnJfL+dqEixrG+HfulpNzmppn648Yb+PvCE1apq48/96xGxKP8 QhsaGsGhvDIUOpiw0X1xc6OS3ijU1NwwTNMd6VMOb1WaZLUZ8L6i+zouoieSiRSPBUWd JG9d/xGIQWLVOSsdwwIxmnQ9D0Kj9S2Ch5cWMTkdhhgGhIO5KwqPj/L9pqxPISQGakVh myb871bPBZgChXATClYvOiCw2bAOkM3k3GIdppUjKx/gX9UhmgnAbCVJJjroe0aBIjKn N9mA==
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; bh=Ro6Rk72CzPJwh4AjD/NBIy/hGV6lYup9gMAuA/sY2pk=; b=LQ3Gj+B+2nwE3tsH8cDU/0Kih1eRfvSmYqeRcXW02p7ToYx+0uucdeSojWx9Tt0KyI Awjo24hEDaEzYwUetvFqR3fe9zC6oH8aDikRX7gdeBMWo+zdsDyMt8PrQXffYb5W3jXS PVaqCf12pbZfqT8Pmat8l54aWdHPT0gTihJuCIEhJ38fMDnZmoeUCUrayqGsoAdU9MeK 4c6/yl40Gco/jKA1ZqdR0Vc/xIyygbzCah+3IscKQoAeoDUclScniT/YV/m3pZs8ZOLZ ikIM/gwUF/BkVfQZh8pNDUYsFjyGOGQD4ycAjVBOfuOprcYcHgpj56y9IJVdaE5GmCyc 3c5Q==
X-Gm-Message-State: ALyK8tK+w4jhgEeHtFQq4MRptUwlglacWzTD1fslyWqSGVgwzwSWIOOdft/PZowRMrYxJ0i5AioqwLkVTn9Hbw==
X-Received: by 10.31.60.204 with SMTP id j195mr8106576vka.132.1468523622011; Thu, 14 Jul 2016 12:13:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 12:13:41 -0700 (PDT)
In-Reply-To: 
References: 
From: Andy Bierman 
Date: Thu, 14 Jul 2016 12:13:41 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Content-Type: multipart/alternative; boundary=001a1142fff0d5a88d05379d4c4a
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 19:13:46 -0000

--001a1142fff0d5a88d05379d4c4a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

IMO NETCONF locks are not well designed at all.
For example, you are not even allowed to lock multiple datastores at once.
You are forced to lock 1 at a time, and if 2 clients are doing this at the
same time,
it can lead to a deadlock between them (Each 1 holding 1 lock waiting for
the other)

The shared candidate is sort of a disaster but if you want to use it
then you will need to invent your own "git update".  The reason nobody
implements
:candidate and :writable-running together is because there is no way to
synch
the candidate if running has been changed underneath it.

A concurrent write database is not "first writer wins, everybody else blows
up".


Andy



On Thu, Jul 14, 2016 at 12:03 PM, Sterne, Jason (Nokia - CA) <
jason.sterne@nokia.com> wrote:

> Hi all,
>
> I=E2=80=99m looking for opinions on how a client & server might interact =
for the
>  RPC when a server supports both writable-running and candidate DS.
>
> I suspect this is an unusual situation -> does anyone out there work with
> or have a server implementation that supports both ?
>
> The spirit of a  is to reserve exclusive access to alter the
> configuration of the device, and to prevent other clients (or management
> interfaces) from altering the config in the meantime.  I realize that in
> theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant) but I th=
ink that might be
> too simplistic for a system with both writable-running and candidate.
>
> In a server that supports both writable-running & candidate, it seems to
> make sense that a  of the running DS would also cause the server to
> implicitly lock the candidate (or at least reject a lock request of the
> candidate).  Otherwise (i.e. accepting a subsequent lock of the candidate=
)
> the client may assume since it has the candidate lock then it has the
> exclusive rights to the config and can happily edit & commit the config.
> It would be confusing to error on the commit (due to locking) after havin=
g
> accepted a lock.
>
> Similarly for the reverse situation -> if a client takes a candidate
>  then couldn=E2=80=99t it assume that nobody can subsequently block=
 their
> commit by taking a lock of the running DS ?
>
> It seems like the server should manage this interaction and avoid giving
> an =E2=80=9COK=E2=80=9D to clients taking the two locks on the two datast=
ores.
>
> On the other hand this could all be left up to the clients to deal with.
> Clients would have to see that a server has both a writeable-running and =
a
> candidate DS and take a lock of both.   But that would require all client=
s
> to have that behavior (instead of the server that supports the 2 DSes
> dealing with this).  It also has race conditions where the client takes 1
> lock but someone else gets the second lock.
>
> Opinions appreciated.
> Regards,
> Jason
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--001a1142fff0d5a88d05379d4c4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

IMO NETCONF locks are not well desi=
gned at all.
For example, you are not even allowed to lock multip=
le datastores at once.
You are forced to lock 1 at a time, and if=
 2 clients are doing this at the same time,
it can lead to a dead=
lock between them (Each 1 holding 1 lock waiting for the other)
<=
br>
The shared candidate is sort of a disaster but if you want to=
 use it
then you will need to invent your own "git update&qu=
ot;.=C2=A0 The reason nobody implements
:candidate and :writable-=
running together is because there is no way to synch
the candidat=
e if running has been changed underneath it.

A con=
current write database is not "first writer wins, everybody else blows=
 up".


Andy



On Thu, Jul 14, 2016 at 12:03 PM, Sterne, Jason (Nokia - CA) <ja=
son.sterne@nokia.com> wrote:


Hi all,


=C2=A0


I=E2=80=99m looking for opinions on how a client & server might in=
teract for the <lock> RPC when a server supports both writable-runnin=
g and candidate DS.=C2=A0 


=C2=A0


I suspect this is an unusual situation -> does anyone out there wor=
k with or have a server implementation that supports both ?


=C2=A0


The spirit of a <lock> is to reserve exclusive access to alter t=
he configuration of the device, and to prevent other clients (or management=
 interfaces) from altering the config in the meantime.=C2=A0 I realize that=
 in theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant)
but I think that might be too simplistic for a system with both writable-ru=
nning and candidate.


=C2=A0


In a server that supports both writable-running & candidate, it se=
ems to make sense that a <lock> of the running DS would also cause th=
e server to implicitly lock the candidate (or at least reject a lock reques=
t of the candidate).=C2=A0 Otherwise (i.e. accepting
a subsequent lock of the candidate) the client may assume since it has the =
candidate lock then it has the exclusive rights to the config and can happi=
ly edit & commit the config.=C2=A0 It would be confusing to error on th=
e commit (due to locking) after having accepted
a lock.


=C2=A0


Similarly for the reverse situation -> if a client takes a candidat=
e <lock> then couldn=E2=80=99t it assume that nobody can subsequently=
 block their commit by taking a lock of the running DS ?


=C2=A0


It seems like the server should manage this interaction and avoid givi=
ng an =E2=80=9COK=E2=80=9D to clients taking the two locks on the two datas=
tores.


=C2=A0


On the other hand this could all be left up to the clients to deal wit=
h.=C2=A0 Clients would have to see that a server has both a writeable-runni=
ng and a candidate DS and take a lock of both.=C2=A0=C2=A0 But that would r=
equire all clients to have that behavior (instead
of the server that supports the 2 DSes dealing with this).=C2=A0 It also ha=
s race conditions where the client takes 1 lock but someone else gets the s=
econd lock.


=C2=A0


Opinions appreciated.


Regards,


Jason 


=C2=A0






_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a1142fff0d5a88d05379d4c4a--


From nobody Thu Jul 14 12:17:55 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96DF12D198 for ; Thu, 14 Jul 2016 12:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTNnY3Q3bAZm for ; Thu, 14 Jul 2016 12:17:50 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8338212D103 for ; Thu, 14 Jul 2016 12:17:49 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id o63so125572960vkg.1 for ; Thu, 14 Jul 2016 12:17:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d61MvlShJkE2MXajvJ7gZorCTM6QL44YbqjqkeaB+BM=; b=ZYwRBdNx1yhERf72oZZ76cL+PYSeZhAwvxBA+OVWEDjKB3uZyrGSiUn27yEjl0jZNr PepzwAsMQpmyiM+el5o8+33PdxggfLMMgFrEYyC+fm+FWW5OswEn528WLvlwrmxrQeoJ ix5rnGWfQtRRQvM/whto4kMuO/5JoTJ3uFIiUaYOibOgAZ3fYeZ9zhRRxgDQ1NWNXYcC X/QfJMG6zmYwXIBTxHl+Yl6IROfnTsVUiXRUSUj2vYNJfQX35ymGE1SzAU2Rb8iIK2QB EeD2KGvfxfAd4rFP3dytcJrG0w9iKUEwG5sx5mvYE9GPA+HwpadN8qUW8hQXr/C91nq4 oxLw==
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; bh=d61MvlShJkE2MXajvJ7gZorCTM6QL44YbqjqkeaB+BM=; b=jANpy6RXakEEivbflh9O+UeiLJk0yELt9/Uvivy4XtnwSc5iFt2wopWr7BB52PiVAV g+Vhk+mM6hodyiBttTOy/BpXUeAPRPMebbGmE8opDMb9opjIj3D9XwCdw4zPZXMCsD78 NtqSUm/SUEayZSyf7PtV2xtJaFT1Yp6p8UjZpfSB+ME7OvcSJlZfScDzdc86B3Ev0EDf tK/Gf08GD5SVSKcEFyXcb6YVWjJaDyzA+4QBN1Rv/XPAFhwAJq0kG93+E/E2nhtqYDQL d11AnV06JGMWG21+RyLVwLw9h0qXKgMGvV8L9frRzstA6p+dHLXuGtUMoRSklYBJ4jVT O0iw==
X-Gm-Message-State: ALyK8tL6v8e0tQOBRu6xZkxKugZ1yTYjlazB7rri23nAX68U+5HqcNrU0mywZ0NsSXRSd4B1vfqEdHY0QqywIA==
X-Received: by 10.31.9.65 with SMTP id 62mr7947564vkj.89.1468523868573; Thu, 14 Jul 2016 12:17:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 12:17:47 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>      
From: Andy Bierman 
Date: Thu, 14 Jul 2016 12:17:47 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Content-Type: multipart/alternative; boundary=001a11440b6487e39c05379d5bfc
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 19:17:54 -0000

--001a11440b6487e39c05379d5bfc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 14, 2016 at 12:08 PM, Sterne, Jason (Nokia - CA) <
jason.sterne@nokia.com> wrote:

> I guess I don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=
=9D.  They are just
> structure and filtered out when empty.  I don=E2=80=99t really see this a=
s the
> server =E2=80=9Cdeleting=E2=80=9D those containers.  It just suppresses t=
hem in
>  output.
>
>
>

Please show me the RFC text that says the server can filter out NP
containers.
All config=3Dtrue data nodes are config.
A false must-stmt in an NP-container is still an error.
As Lada has pointed out many times, the text about
NP containers not being part of the data model is just wrong.




> The server should not error in the cases Mahesh & Einar show -> the
> presence/existence of NP-containers shouldn=E2=80=99t really affect behav=
ior (since
> they aren=E2=80=99t really config).
>
>
>
> But I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs to g=
uard=E2=80=9D.  Do you
> agree that the server should not error in those cases below ?
>


The YANG text says a server MAY delete an empty NP container.
Using default-operation=3Dnone implies that the client is sure the nodes fo=
r
operation=3Dnone
actually exist.  Because of this YANG detail, the client cannot be sure so
using
default-operation=3Dnone may not work.



>
>
> Jason
>

Andy


>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Thursday, July 14, 2016 15:01
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Xiang Li; Netconf
> *Subject:* Re: [Netconf] What should a server response be?
>
>
>
> Hi,
>
>
>
> The problem is this horrible text in the YANG RFC:
>
>
>
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.5.8
>
>
>
>    If a container does not have a "presence" statement and the last
>
>    child node is deleted, the NETCONF server MAY delete the container.
>
>
>
> This is a good example of why is a bad idea to define NETCONF protocol
> details
>
> in the YANG spec.
>
>
>
> NETCONF itself never says it is OK for the server to delete edits from th=
e
> client.
>
> (This is especially dumb in the candidate config because its sole purpose
> is
>
> to be a scratchpad for incremental edits)
>
>
>
> So I have to say to server is allowed to delete the empty NP containers,
>
> and the manager needs to guard against server implementations that delete
>
> empty NP containers.
>
>
>
> This sort of variability without purpose harms interoperability.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 14, 2016 at 11:47 AM, Sterne, Jason (Nokia - CA) <
> jason.sterne@nokia.com> wrote:
>
> IMO those examples from Mahesh and Einar should all succeed.
>
>
>
> But after the 1st request I don=E2=80=99t think a  is require=
d to
> return any empty NP containers.  So I=E2=80=99m not sure that I=E2=80=99m=
 totally in
> agreement with Xiang Li.  A create of an NP container can return an OK bu=
t
> then a subsequent  can filter out empty NP containers.
>
>
>
> Returning NP containers (whether they were explicitly created or not)
> seems like it would product a lot of unnecessary noise in a response.
>
>
>
> Regards,
>
> Jason
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, July 14, 2016 12:16
> *To:* Xiang Li
> *Cc:* Netconf
> *Subject:* Re: [Netconf] What should a server response be?
>
>
>
> Hi,
>
>
>
> I can see the confusion because of the sloppy text in RFC 6241.
>
> NP containers have always been a problem.  The NETMOD WG did a poor job
>
> of defining them in an interoperable way.
>
>
>
> IMO the server should not delete NP containers for exactly the cases you
> point out.
>
> The server does not know the client's intentions so why is it deleting
> nodes?
>
> Also, YANG 1.1 XPath rules treat NP containers as if they are always
> present.
>
> (So the text about MAY delete NP containers is even more confusing).
>
>
>
>
>
> Andy
>
>
>
>
>
> On Thu, Jul 14, 2016 at 9:10 AM, Andy Bierman  wrote:
>
> Hi,
>
>
>
> Mahesh asked me to be more specific.
>
> If the server is returning  for edit 1 but the candidate datastore
>
> is still empty after edit 1 then this is a server bug.
>
>
>
> Andy
>
>
>
> On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman  wrote:
>
> Hi,
>
>
>
> The implementation has bugs.
>
> The RFC is clear wrt/ operation=3Dnone vs merge or replace.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li  wrote:
>
> On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>
>
>
> On Jul 12, 2016, at 9:28 AM, Xiang Li  wrote:
>
>
>
> On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
>
> The Opendaylight controller is constructing this particular set of
>  requests as part of a single transaction. The response of t=
he
> server is to reject the configuration that the particular node (evpn
> container) does not exist.
>
>
>
> However, if the default-operation=3Dnone is removed or changed to replace=
,
> the server responds with an RPC OK.
>
>
>
> Is the server right in its interpretation of what RFC 6241 says? In
> particular, the way the server is interpreting this request is as follows
> from Section 7.2 of the RFC:
>
>
>
>          none:  The target datastore is unaffected by the configuration
>
>             in the  parameter, unless and until the incoming
>
>             configuration data uses the "operation" attribute to request
>
>             a different operation.  If the configuration in the 
>
>             parameter contains data for which there is not a
>
>             corresponding level in the target datastore, an 
>
>             is returned with an  value of data-missing.
>
>             Using "none" allows operations like "delete" to avoid
>
>             unintentionally creating the parent hierarchy of the element
>
>             to be deleted.
>
>
>
> and then this:
>
>
>
>       operation:  Elements in the  subtree MAY contain an
>
>          "operation" attribute, which belongs to the NETCONF namespace
>
>          defined in Section 3.1 .  The attribute identifies the point in
>
>          the configuration to perform the operation and MAY appear on
>
>          multiple elements throughout the  subtree.
>
>
>
>
>
> *1st request:*
>
>
>
> 
>
>   
>
>     
>
>       
>
>     
>
>     rollback-on-error
>
>     
>
>       
>
>         
>
>       
>
>     
>
>   
>
> 
>
> ##
>
>
>
> The container evpn in this case is a non-presence container and does not
> contain any mandatory leafs or default statements. The server therefore
> interprets that nothing has to be done here, as it is not required to
> create a empty container.
>
>
>
>
>
> I think the container node needs to be created when you are merging to
> create new nodes explicitly.
> RFC6020
> 7.5.  The container Statement
>    7.5.8.  NETCONF  Operations
>
>     When a NETCONF server processes an  request, the
>
>     elements of procedure for the container node are:
>
>
>
>       If the operation is "merge" or "replace", the node is created if
>
>       it does not exist.
>
>
>
> It makes no sense to me for the server to return ok but actually does not
> create that
> container node in this case.
>
>
>
> And that is the clarification I am seeking. Note, it is an empty
> non-presence container. Should the server create this empty container, an=
d
> if so how would it be represented in the config tree? In this particular
> case, the request is followed by child nodes. What happens if no child
> nodes are created?
>
>
>
>
> My understanding is that it does not matter if it is a presence container
> or not in this case
> , nor if there are child nodes included  to be created.
>
>
>
>
> The server may delete an empty container node but only when you deleting
> stuff:
>
> If a container does not have a "presence" statement and the last
>
>    child node is deleted, the NETCONF server MAY delete the container.
>
>
>
> For a delete it is clear. But the RFC is silent for a create (and the
> default operation of merge).
>
>
> I think RFC6020 7.5.8.  "NETCONF  Operations" (for container
> node)
> covers this :
>
> -    When a NETCONF server processes an  request, the
>
> -    elements of procedure for the container node are:
>
> -
>
> -      If the operation is "merge" or "replace", the node is created if
>
> -      it does not exist.
>
>
>
> -      If the operation is "create", the node is created if it does not
>
> -      exist.  If the node already exists, a "data-exists" error is
>
> -      returned.
>
>
>
> If a non-presence empty container can be deleted, why should it be create=
d?
>
>
>
> It is because the client is sending an   to create this
> container explicitly.
> If a client wants to create *only* a container node, it can certainly do
> so without
> having to specify any child instance nodes. If the server returns "Ok" fo=
r
> such
> a request then it must mean it has indeed created the container node.
>
> I think it makes little sense for a server to return "Ok" but does not
> create
> the container node (thinking nothing needs to be done if there are no
> child nodes
> included in the same request). The "Ok" response must mean something, i.e=
.,
> the create/merge/replace operations has actually succeeded in creating th=
e
> container node in question.
>
> -Xiang
>
>
>
> Thanks.
>
>
>
>
>
> *2nd request:*
>
>
>
> 
>
>   
>
>     
>
>       
>
>     
>
>     none
>
>     rollback-on-error
>
>     
>
>       
>
>         
>
>            xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replac=
e">
>
>             
>
>             
>
>           
>
>         
>
>       
>
>     
>
>   
>
> 
>
> ##
>
>
>
> In the second request, the default-operation=3Dnone again seems to imply
> that nothing needs to be done for creation of the evpn node. Therefore by
> the time the evpn-load-balancing request rolls around, the request is
> rejected as the parent container does not exist. As stated earlier, if th=
e
> default-operation is removed (causing a default of merge) or replaced wit=
h
> a replace, the transaction succeeds.
>
>
>
> A second interpretation to this transaction is that the server should hav=
e
> created the evpn node as part of the first request, and that the none
> operation was implying that the node had already been created.
>
>
>
>
>
> If the server returns ok for the first , then it means it ha=
s
> successfully created the top two container nodes in the hierarchy:
>
>       
>
>         
>
> then the second request should have succeeded.
>
>
>
> -Xiang Li
>
>
>
> Mahesh Jethanandani
>
> mjethanandani@gmail.com
>
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
>
>
>
>
>

--001a11440b6487e39c05379d5bfc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 14, 2016 at 12:08 PM, Sterne, Jason (Nokia - CA) <ja=
son.sterne@nokia.com> wrote:




I guess I don=E2=80=99t r=
eally see NP-containers as =E2=80=9Cconfig=E2=80=9D.=C2=A0 They are just st=
ructure and filtered out when empty.=C2=A0 I don=E2=80=99t really see this =
as the server =E2=80=9Cdeleting=E2=80=9D
 those containers.=C2=A0 It just suppresses them in <get-config> outp=
ut.=C2=A0=C2=A0 


=C2=A0
<=
/div>

Please show me the RFC text tha=
t says the server can filter out NP containers.
All config=3Dtrue=
 data nodes are config.
A false must-stmt in an NP-container is s=
till an error.
As Lada has pointed out many times, the text about=

NP containers not being part of the data model is just wrong.


=C2=A0


The server should not err=
or in the cases Mahesh & Einar show -> the presence/existence of NP-=
containers shouldn=E2=80=99t really affect behavior (since they aren=E2=80=
=99t
 really config).


=C2=A0


But I=E2=80=99m not posit=
ive what you mean by =E2=80=9Cmanager needs to guard=E2=80=9D.=C2=A0 Do you=
 agree that the server should not error in those cases below ?


The YANG text say=
s a server MAY delete an empty NP container.
Using default-operat=
ion=3Dnone implies that the client is sure the nodes for operation=3Dnone
actually exist.=C2=A0 Because of this YANG detail, the client cann=
ot be sure so using
default-operation=3Dnone may not work.
<=
div>
=C2=A0


=C2=A0


Jason

Andy
=C2=A0
=



=C2=A0




From: Andy Bie=
rman [mailto:andy@y=
umaworks.com]


Sent: Thursday, July 14, 2016 15:01

To: Sterne, Jason (Nokia - CA)

Cc: Xiang Li; Netconf

Subject: Re: [Netconf] What should a server response be?




=C2=A0




Hi,




=C2=A0






The problem is this horrible text in the YANG RFC:






=C2=A0







=C2=A0






=C2=A0=C2=A0 If a container does not have =
a "presence" statement and the last


=C2=A0=C2=A0 child node is deleted, the NE=
TCONF server MAY delete the container.


=C2=A0


This is a good example of why is a bad idea to defin=
e NETCONF protocol details






in the YANG spec.






=C2=A0






NETCONF itself never says it is OK for the server to=
 delete edits from the client.






(This is especially dumb in the candidate config bec=
ause its sole purpose is






to be a scratchpad for incremental edits)<=
/u>






=C2=A0






So I have to say to server is allowed to delete the =
empty NP containers,






and the manager needs to guard against server implem=
entations that delete






empty NP containers.






=C2=A0






This sort of variability without purpose harms inter=
operability.






=C2=A0






=C2=A0






Andy






=C2=A0






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Thu, Jul 14, 2016 at 11:47 AM, Sterne, Jason (Nok=
ia - CA) <ja=
son.sterne@nokia.com> wrote:






IMO those examples from M=
ahesh and Einar should all succeed.


=C2=A0


But after the 1st request I don=E2=80=99t think a <get-config> is required to retur=
n any empty
 NP containers.=C2=A0 So I=E2=80=99m not sure that I=E2=80=99m totally in a=
greement with Xiang Li.=C2=A0 A create of an NP container can return an OK =
but then a subsequent <get-config> can filter out empty NP containers=
.


=C2=A0


Returning NP containers (=
whether they were explicitly created or not) seems like it would product
 a lot of unnecessary noise in a response.


=C2=A0


Regards,=



Jason


=C2=A0




From: Netconf =
[mailto:netco=
nf-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: Thursday, July 14, 2016 12:16

To: Xiang Li

Cc: Netconf

Subject: Re: [Netconf] What should a server response be?




=C2=A0




Hi,




=C2=A0






I can see the confusion because of the sloppy text i=
n RFC 6241.






NP containers have always been a problem.=C2=A0 The =
NETMOD WG did a poor job






of defining them in an interoperable way.<=
/u>






=C2=A0






IMO the server should not delete NP containers for e=
xactly the cases you point out.






The server does not know the client's intentions=
 so why is it deleting nodes?






Also, YANG 1.1 XPath rules treat NP containers as if=
 they are always present.






(So the text about MAY delete NP containers is even =
more confusing).






=C2=A0






=C2=A0






Andy






=C2=A0








=C2=A0




On Thu, Jul 14, 2016 at 9:10 AM, Andy Bierman <andy@yumaworks.com> wrote:




Hi,




=C2=A0






Mahesh asked me to be more specific.





If the server is returning <ok/> for edit 1 bu=
t the candidate datastore






is still empty after edit 1 then this is a server bu=
g.






=C2=A0






Andy






=C2=A0




On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman <andy@yumaworks.com> wrote:




Hi,




=C2=A0






The implementation has bugs.






The RFC is clear wrt/ operation=3Dnone vs merge or r=
eplace.






=C2=A0






=C2=A0






=C2=A0






Andy






=C2=A0








=C2=A0




On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li <xiangli@seguesoft.com<=
/a>> wrote:






On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:<=
/u>






=C2=A0







=C2=A0








On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:<=
/u>








The Opendaylight controller is constructing this par=
ticular set of <edit-config> requests as part of a single transaction=
. The response of the server is to reject the configuration
 that the particular node (evpn container) does not exist.=C2=A0<=
/u>






=C2=A0






However, if the default-operation=3Dnone is removed =
or changed to replace, the server responds with an RPC OK.





=C2=A0






Is the server right in its interpretation of what RF=
C 6241 says? In particular, the way the server is interpreting this request=
 is as follows from Section 7.2 of the RFC:






=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 none:=C2=A0 The target datastore is unaffected by the configuratio=
n


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the <config> parameter, unless and unt=
il the incoming


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 configuration data uses the "operation&quo=
t; attribute to request


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 a different operation. =C2=A0If the conf=
iguration in the <config>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 par=
ameter contains data for which there is not a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cor=
responding level in the target datastore, an <rpc-error>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is =
returned with an <error-tag> value of data-missing.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Usi=
ng "none" allows operations like "delete" to avoid


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uni=
ntentionally creating the parent hierarchy of the element

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0to =
be deleted.






=C2=A0






and then this:






=C2=A0






=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operation:=C2=A0 Elements in the <co=
nfig> subtree MAY contain an


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "operation"=
 attribute, which belongs to the NETCONF namespace


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined in Section=
 3.1.=C2=A0 The attribute identifies the =
point in


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 the configuration to perform the operation and MAY appear on


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 multiple elements throughout the <config> subtree.






=C2=A0






=C2=A0








1st=C2=A0request:






=C2=A0






<rpc xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0" message-id=3D"m-23&qu=
ot;>






=C2=A0 <edit-con=
fig>






=C2=A0=C2=A0=C2=A0 =
<target>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <candidate/>






=C2=A0=C2=A0=C2=A0 =
</target>






=C2=A0=C2=A0=C2=A0 =
<error-option>rollback-on-error</error-option>=







=C2=A0=C2=A0=C2=A0 =
<config>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <evpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-X=
R-l2vpn-cfg">






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-tables/>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </evpn>






=C2=A0=C2=A0=C2=A0 =
</config>






=C2=A0 </edit-co=
nfig>






</rpc>=







##=







=C2=A0






The container evpn in this case is a non-presence co=
ntainer and does not contain any mandatory leafs or default statements. The=
 server therefore interprets that nothing has to be
 done here, as it is not required to create a empty container.






=C2=A0












I think the container node needs to be created when you are merging to crea=
te new nodes explicitly.

RFC6020 

7.5.=C2=A0 The container Statement

=C2=A0=C2=A0 7.5.8.=C2=A0 NETCONF <edit-config> Operations<=
/u>


=C2=A0=C2=A0=C2=A0 When a NETCONF server processes an <edit-config&=
gt; request, the


=C2=A0=C2=A0=C2=A0 elements of procedure for the container node are:


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operation is "merge" o=
r "replace", the node is created if


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it does not exist.


=C2=A0


It makes no sense to me for the server to return ok =
but actually does not create that

container node in this case.










=C2=A0




And that is the clarification I am seeking. Note, it=
 is an empty non-presence container. Should the server create this empty co=
ntainer, and if so how would it be represented in
 the config tree? In this particular case, the request is followed by child=
 nodes. What happens if no child nodes are created?






=C2=A0








My understanding is that it does not matter if it is a presence container o=
r not in this case

, nor if there are child nodes included=C2=A0 to be created.




















The server may delete an empty container node but only when you deleting st=
uff:






If a container does not have a "presence" statement and the =
last


=C2=A0=C2=A0 child node is deleted, the NETCONF server MAY delete the =
container.










=C2=A0




For a delete it is clear. But the RFC is silent for =
a create (and the default operation of merge).






I think RFC6020 7.5.8.=C2=A0 "NETCONF <edit-config> Operations&q=
uot; (for container node)

covers this : 


-=C2=A0=C2=A0=C2=A0 When a NETCONF server processes an <edit-config=
> request, the


-=C2=A0=C2=A0=C2=A0 elements of procedure for the container node are:<=
u>


-


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operation is "merge" =
or "replace", the node is created if


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it does not exist.


=C2=A0=C2=A0=C2=A0=C2=A0 


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the operation is "create"=
, the node is created if it does not


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exist.=C2=A0 If the node already exist=
s, a "data-exists" error is


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 returned.











If a non-presence empty container can be deleted, wh=
y should it be created?








It is because the client is sending an <edit-config>=C2=A0 to create =
this container explicitly.

If a client wants to create *only* a container node, it can certainly do so=
 without


having to specify any child instance nodes. If the server returns "Ok&=
quot; for such

a request then it must mean it has indeed created the container node.



I think it makes little sense for a server to return "Ok" but doe=
s not create 

the container node (thinking nothing needs to be done if there are no child=
 nodes

included in the same request). The "Ok" response must mean someth=
ing, i.e.,

the create/merge/replace operations has actually succeeded in creating the =


container node in question.



-Xiang








=C2=A0






Thanks.






=C2=A0<=
/p>





=C2=A0<=
/p>





2nd=C2=A0request:






=C2=A0






<rpc xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0" message-id=3D"m-24&qu=
ot;>






=C2=A0 <edit-con=
fig>






=C2=A0=C2=A0=C2=A0 =
<target>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <candidate/>






=C2=A0=C2=A0=C2=A0 =
</target>






=C2=A0=C2=
=A0=C2=A0 <default-operation>none</default-operation>=







=C2=A0=C2=A0=C2=A0 =
<error-option>rollback-on-error</error-option>=







=C2=A0=C2=A0=C2=A0 =
<config>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <evpn xmlns=3D"http://cisco.com/ns/yang/Cisco-IOS-X=
R-l2vpn-cfg">






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-tables>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-load-balancing xmlns:a=3D&quo=
t;urn:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replace=
">






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <enable/><=
/u>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-flow-label/>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </evpn-load-balancing>=







=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </evpn-tables>






=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 </evpn>






=C2=A0=C2=A0=C2=A0 =
</config>






=C2=A0 </edit-co=
nfig>






</rpc>=







##=







=C2=A0




In the second request, the default-operation=3Dnone =
again seems to imply that nothing needs to be done for creation of the evpn=
 node. Therefore by the time the evpn-load-balancing
 request rolls around, the request is rejected as the parent container does=
 not exist. As stated earlier, if the default-operation is removed (causing=
 a default of merge) or replaced with a replace, the transaction succeeds.<=
u>






=C2=A0






A second interpretation to this transaction is that =
the server should have created the evpn node as part of the first request, =
and that the none operation was implying that the
 node had already been created.






=C2=A0












If the server returns ok for the first <edit-config>, then it means i=
t has successfully created the top two container nodes in the hierarchy:=





=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <evpn >




=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <evpn-tables>



then the second request should have succeeded.
















-Xiang Li










=C2=A0






Mahesh Jethanandani







=C2=A0




=C2=A0




=C2=A0






_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




=C2=A0






=C2=A0








=C2=A0










=C2=A0












--001a11440b6487e39c05379d5bfc--


From nobody Thu Jul 14 12:59:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2BA12D87A for ; Thu, 14 Jul 2016 12:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJzOGtVnNq_Z for ; Thu, 14 Jul 2016 12:59:35 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E81812D89F for ; Thu, 14 Jul 2016 12:59:35 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id t190so33020278pfb.3 for ; Thu, 14 Jul 2016 12:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=o/XJ3k4iEGfrdlk2em0CBugRySx45k1QEdQig2DRbvk=; b=Q7idvnMVJ1oVYkKsdTWzjr1f3fUNwo89HHrWuNsjLfG34byVeLAcgEtMEScP0pnC6M 92LpYf3VVxmdXMiR85A2/+CdCYt8uhCA4Zq+dm0A5j+ns3prFC2R/2cfcmzH4U8c5dEr OVVhHEqusEZ1ROJhPsyTCVYGoOSIe3VYuKT+7E9JLz2RoNueLrd9doFDw6GsYlE3yYss wvEBn+l3AgeWBjbSfYWHmJqvLCiulWQFaiNzvwAw1EWJ76qBbhcAn45U0qJzmgH2W/RF YBtkbTWjOICiEibhff4cj1G5Vu8sRoIT1oeiEPGmonSHzYvXm1ZZ98+DLt+vBF27rzxh 5/Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=o/XJ3k4iEGfrdlk2em0CBugRySx45k1QEdQig2DRbvk=; b=RHtahPDJKpX9XMorkjnCijG9YH+BRFygm3PtIZ/iyjl035RlsIpxsuTo8Z6z90EtNS +zdvjukerYxK0/7ySFwK9KkajXg/9zcm/BwHon0ncADEp/6vZF6sP5wYNbg6XC5fOiCU 1pNB6UngcVGT9m7Mb+/JLFvUoQ0H4yS7xE76Izdw86gJjcQwF1d54lSAWBYIxsEdODql FEzzcGcXTd4ZgsouwuZD0j1X/HCdkw+AZGCVFa5tNqE5gkoV5qEE2HEfMzvfgI7NBtWs CzmoevdFllrk5AzM97TpotGvjDA7xyt4JOagifS5bxMqGWX5TiYWIC4C+z7VLkZ8myrT RTzQ==
X-Gm-Message-State: ALyK8tJdjSz1BpCYCU/hksvUCARI3jk7r6AiRRnEbe7lN5Zkc7mSvdP/N69LpYrQ/3jfrg==
X-Received: by 10.98.28.142 with SMTP id c136mr15276238pfc.131.1468526374775;  Thu, 14 Jul 2016 12:59:34 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1003::6a6? ([2001:420:c0c8:1003::6a6]) by smtp.gmail.com with ESMTPSA id g13sm6262223pfb.7.2016.07.14.12.59.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 12:59:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_855187CB-524A-4205-AE80-E650680BFC5B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Thu, 14 Jul 2016 12:59:31 -0700
Message-Id: <8A4585AC-DAF6-4955-8599-81C8A2152176@gmail.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>       
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 19:59:37 -0000

--Apple-Mail=_855187CB-524A-4205-AE80-E650680BFC5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 14, 2016, at 12:17 PM, Andy Bierman  wrote:
>=20
> The YANG text says a server MAY delete an empty NP container.
> Using default-operation=3Dnone implies that the client is sure the =
nodes for operation=3Dnone
> actually exist.  Because of this YANG detail, the client cannot be =
sure so using
> default-operation=3Dnone may not work.

That to me is where the disconnect lies between the client and server. =
The client is assuming that the nodes were created as part of the first =
request, while the server is =E2=80=9Cdeleting" it because it is an =
empty NP container. Can the text be clarified to make it clearer? =
Something along the lines that a NP container should be deleted only if =
no other child nodes exist in the same transaction.

Semantically, it would have made no difference to the operation if the =
client decided not to set the default-operation=3Dnone or even set it to =
=E2=80=98replace' and the server would have to respond with an ok.

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_855187CB-524A-4205-AE80-E650680BFC5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jul 14, 2016, at 12:17 PM, Andy Bierman <andy@yumaworks.com> =
wrote:

The YANG text says a server =
MAY delete an empty NP container.
Using default-operation=3Dnone implies that the client =
is sure the nodes for operation=3Dnone
actually exist.  Because of this YANG detail, the =
client cannot be sure so using
default-operation=3Dnone may not =
work.

That to me is =
where the disconnect lies between the client and server. The client is =
assuming that the nodes were created as part of the first request, while =
the server is =E2=80=9Cdeleting" it because it is an empty NP container. =
Can the text be clarified to make it clearer? Something along the lines =
that a NP container should be deleted only if no other child nodes exist =
in the same transaction.

Semantically,=
 it would have made no difference to the operation if the client decided =
not to set the default-operation=3Dnone or even set it to =E2=80=98replace=
' and the server would have to respond with an ok.



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_855187CB-524A-4205-AE80-E650680BFC5B--


From nobody Thu Jul 14 13:00:44 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E30612D5AB for ; Thu, 14 Jul 2016 13:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NOMe9GLeNrh for ; Thu, 14 Jul 2016 13:00:42 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4012312D93A for ; Thu, 14 Jul 2016 13:00:38 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id t190so33027735pfb.3 for ; Thu, 14 Jul 2016 13:00:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=X8vA6sv4TAIxvcdHa5fLvh6RAX6Flq8DJRfTZiIlrXM=; b=BYgVJp/s+IQSNgdhyqnCt9+EvALDGZWwueuHx9WBxbkAi3+ItreYbEayWV1+Utue2x 4MWfuKb2XgELSHgmHYmm/I0pWW42vHvcCpyHurbTtZgj56Qcq7mvg0aUmfe681+fND+3 ooWEWzf9+eQZhLE+mlg1HJ4mP3V6SK5QmxTn66vHX69qbO7ZVPBFEKfGgVQ0km5z+Oa8 FVVvR4sdwHEBeJV0m+hS1byibXgJszENrSBKWBhkAmPRa6K4wF5u1yD/rroQzKrLgMdn Mjc7oN6Y43x18VKLHSPGnNpNeblvey9f+7pFcsBAtVTNRqdCtqCy8w+leCxzpmvDDirh gFFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=X8vA6sv4TAIxvcdHa5fLvh6RAX6Flq8DJRfTZiIlrXM=; b=NwXsHXvX3PdksBeRCLlaDtojGsruchEWWKWT6CHX2QL5IbYJ66VzsN6eRhLwMDCZqE zTZzb4/3IsuAtYHvJwR0AWQCxn95X7LSSsXqSOQ8eiSBwgPP3J7g07ye3AZjf/2JtQ3t lu/rm/FgeNTlqmX92WvcZeUb0FpZSIbeQ1CrPQFwWFSkBdmw6hsR8hO+5Q6OMZ6CfRCc I4eDvxtJ4WCxDBUbvysyQ/RSwPYlDSPkumwBnKFw0jFeIC4NwaCmw8d62gzTS7bvX0mO 9iujBVp+RgSmNS/aAOU4z4kv2BtlGBBrhcNk8VF7rErXOD16unb7YgLNFdvJPK/6ioui KYrg==
X-Gm-Message-State: ALyK8tIE/zKnZzVc9P2DiwlfDCdfd4HNcJnVoZTeqARzWOH4+yJriyX+5ezeEB5JX8e+1A==
X-Received: by 10.98.157.154 with SMTP id a26mr15503716pfk.68.1468526437557; Thu, 14 Jul 2016 13:00:37 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1003::6a6? ([2001:420:c0c8:1003::6a6]) by smtp.gmail.com with ESMTPSA id 81sm3526327pfm.90.2016.07.14.13.00.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 13:00:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F25557E-1739-43A9-882D-8221E50087B6"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Thu, 14 Jul 2016 13:00:35 -0700
Message-Id: <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com>
References: 
To: "Sterne, Jason (Nokia - CA)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 20:00:44 -0000

--Apple-Mail=_6F25557E-1739-43A9-882D-8221E50087B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I see clients acquiring lock on the candidate config but not on running. =
You are right that it does not prevent, say RESTCONF or even CLI from =
updating the running-config directly.

A workflow for what should be happening is:

- acquire lock on candidate and running (can create deadlock as Andy =
mentions)
- edit the candidate config
- validate candidate config
- commit candidate to running
- release lock on candidate and running


> On Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia - CA) =
 wrote:
>=20
> Hi all,
> =20
> I=E2=80=99m looking for opinions on how a client & server might =
interact for the  RPC when a server supports both writable-running =
and candidate DS. =20
> =20
> I suspect this is an unusual situation -> does anyone out there work =
with or have a server implementation that supports both ?
> =20
> The spirit of a  is to reserve exclusive access to alter the =
configuration of the device, and to prevent other clients (or management =
interfaces) from altering the config in the meantime.  I realize that in =
theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant) but I =
think that might be too simplistic for a system with both =
writable-running and candidate.
> =20
> In a server that supports both writable-running & candidate, it seems =
to make sense that a  of the running DS would also cause the =
server to implicitly lock the candidate (or at least reject a lock =
request of the candidate).  Otherwise (i.e. accepting a subsequent lock =
of the candidate) the client may assume since it has the candidate lock =
then it has the exclusive rights to the config and can happily edit & =
commit the config.  It would be confusing to error on the commit (due to =
locking) after having accepted a lock.
> =20
> Similarly for the reverse situation -> if a client takes a candidate =
 then couldn=E2=80=99t it assume that nobody can subsequently =
block their commit by taking a lock of the running DS ?
> =20
> It seems like the server should manage this interaction and avoid =
giving an =E2=80=9COK=E2=80=9D to clients taking the two locks on the =
two datastores.
> =20
> On the other hand this could all be left up to the clients to deal =
with.  Clients would have to see that a server has both a =
writeable-running and a candidate DS and take a lock of both.   But that =
would require all clients to have that behavior (instead of the server =
that supports the 2 DSes dealing with this).  It also has race =
conditions where the client takes 1 lock but someone else gets the =
second lock.
> =20
> Opinions appreciated.
> Regards,
> Jason=20
> =20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_6F25557E-1739-43A9-882D-8221E50087B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I see clients acquiring lock on the candidate =
config but not on running. You are right that it does not prevent, say =
RESTCONF or even CLI from updating the running-config =
directly.

A =
workflow for what should be happening is:

- acquire lock on candidate and running =
(can create deadlock as Andy mentions)
- edit the =
candidate config
- validate candidate =
config
- commit candidate to running
- release lock on candidate and running


On =
Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:

Hi =
all,
 
I=E2=80=99m =
looking for opinions on how a client & server might interact for the =
<lock> RPC when a server supports both writable-running and =
candidate DS.  
 
I suspect this is an unusual =
situation -> does anyone out there work with or have a server =
implementation that supports both ?
 
The spirit of a <lock> is to reserve exclusive access =
to alter the configuration of the device, and to prevent other clients =
(or management interfaces) from altering the config in the =
meantime.  I realize that in theory the locks are =E2=80=9Cper-DS=E2=80=
=9D (i.e. independant) but I think that might be too simplistic for a =
system with both writable-running and candidate.
 
In a server that supports both =
writable-running & candidate, it seems to make sense that a =
<lock> of the running DS would also cause the server to implicitly =
lock the candidate (or at least reject a lock request of the =
candidate).  Otherwise (i.e. accepting a subsequent lock of the =
candidate) the client may assume since it has the candidate lock then it =
has the exclusive rights to the config and can happily edit & commit =
the config.  It would be confusing to error on the commit (due to =
locking) after having accepted a lock.
 
Similarly for the reverse =
situation -> if a client takes a candidate <lock> then =
couldn=E2=80=99t it assume that nobody can subsequently block their =
commit by taking a lock of the running DS ?
 
It seems like the server should =
manage this interaction and avoid giving an =E2=80=9COK=E2=80=9D to =
clients taking the two locks on the two datastores.
 
On the other hand this could all =
be left up to the clients to deal with.  Clients would have to see =
that a server has both a writeable-running and a candidate DS and take a =
lock of both.   But that would require all clients to have =
that behavior (instead of the server that supports the 2 DSes dealing =
with this).  It also has race conditions where the client takes 1 =
lock but someone else gets the second lock.
 
Opinions appreciated.
Regards,
Jason 
 
_______________________________________________
Netconf mailing =
list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_6F25557E-1739-43A9-882D-8221E50087B6--


From nobody Thu Jul 14 13:06:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3112D98B for ; Thu, 14 Jul 2016 13:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0TMENQI3dxkL for ; Thu, 14 Jul 2016 13:06:20 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667DE12D96F for ; Thu, 14 Jul 2016 13:06:20 -0700 (PDT)
Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 3EBEA639288EF; Thu, 14 Jul 2016 20:06:17 +0000 (GMT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6EK6Ixd023571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 20:06:19 GMT
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u6EK6IdJ002986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 20:06:18 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 16:06:18 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Mahesh Jethanandani , Andy Bierman 
Thread-Topic: [Netconf] What should a server response be?
Thread-Index: AQHR3esI0j4IVR1/2kW9+f8gjxD6tKAYQ0SQgABICoD//73wYIAARsmAgAALqYD//7358A==
Date: Thu, 14 Jul 2016 20:06:17 +0000
Message-ID: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <8A4585AC-DAF6-4955-8599-81C8A2152176@gmail.com>
In-Reply-To: <8A4585AC-DAF6-4955-8599-81C8A2152176@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC9DFBUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 20:06:22 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCC9DFBUS70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBkb27igJl0IHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gc2F5IOKAnG9ubHkgaWYgbm8gb3RoZXIg
Y2hpbGQgbm9kZXMgZXhpc3QgaW4gdGhlIHNhbWUgdHJhbnNhY3Rpb27igJ0uICBUaG9zZSAyIHJl
cXVlc3RzIHNob3VsZCB3b3JrIGV2ZW4gaWYgdGhlcmUgaXMgYSBjb21taXQgYWZ0ZXIgZWFjaCBv
bmUuDQoNCk1heWJlIHdlIHNob3VsZCBpbnN0ZWFkIGNsYXJpZnkgdGhhdCBhbiBlZGl0IHNob3Vs
ZG7igJl0IGZhaWwgZHVlIHRvIGFuIGFic2VudCBOUC1jb250YWluZXIgPyAgKGkuZS4gYWJzZW5j
ZS9wcmVzZW5jZSBvZiBhbiBOUC1jb250YWluZXIgc2hvdWxkIGJlIOKAnG1vb3TigJ0pLg0KDQpG
cm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21d
DQpTZW50OiBUaHVyc2RheSwgSnVseSAxNCwgMjAxNiAxNjowMA0KVG86IEFuZHkgQmllcm1hbg0K
Q2M6IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpOyBOZXRjb25mDQpTdWJqZWN0OiBSZTogW05l
dGNvbmZdIFdoYXQgc2hvdWxkIGEgc2VydmVyIHJlc3BvbnNlIGJlPw0KDQoNCk9uIEp1bCAxNCwg
MjAxNiwgYXQgMTI6MTcgUE0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0
bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90ZToNCg0KVGhlIFlBTkcgdGV4dCBzYXlzIGEgc2Vy
dmVyIE1BWSBkZWxldGUgYW4gZW1wdHkgTlAgY29udGFpbmVyLg0KVXNpbmcgZGVmYXVsdC1vcGVy
YXRpb249bm9uZSBpbXBsaWVzIHRoYXQgdGhlIGNsaWVudCBpcyBzdXJlIHRoZSBub2RlcyBmb3Ig
b3BlcmF0aW9uPW5vbmUNCmFjdHVhbGx5IGV4aXN0LiAgQmVjYXVzZSBvZiB0aGlzIFlBTkcgZGV0
YWlsLCB0aGUgY2xpZW50IGNhbm5vdCBiZSBzdXJlIHNvIHVzaW5nDQpkZWZhdWx0LW9wZXJhdGlv
bj1ub25lIG1heSBub3Qgd29yay4NCg0KVGhhdCB0byBtZSBpcyB3aGVyZSB0aGUgZGlzY29ubmVj
dCBsaWVzIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgc2VydmVyLiBUaGUgY2xpZW50IGlzIGFzc3Vt
aW5nIHRoYXQgdGhlIG5vZGVzIHdlcmUgY3JlYXRlZCBhcyBwYXJ0IG9mIHRoZSBmaXJzdCByZXF1
ZXN0LCB3aGlsZSB0aGUgc2VydmVyIGlzIOKAnGRlbGV0aW5nIiBpdCBiZWNhdXNlIGl0IGlzIGFu
IGVtcHR5IE5QIGNvbnRhaW5lci4gQ2FuIHRoZSB0ZXh0IGJlIGNsYXJpZmllZCB0byBtYWtlIGl0
IGNsZWFyZXI/IFNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgdGhhdCBhIE5QIGNvbnRhaW5lciBz
aG91bGQgYmUgZGVsZXRlZCBvbmx5IGlmIG5vIG90aGVyIGNoaWxkIG5vZGVzIGV4aXN0IGluIHRo
ZSBzYW1lIHRyYW5zYWN0aW9uLg0KDQpTZW1hbnRpY2FsbHksIGl0IHdvdWxkIGhhdmUgbWFkZSBu
byBkaWZmZXJlbmNlIHRvIHRoZSBvcGVyYXRpb24gaWYgdGhlIGNsaWVudCBkZWNpZGVkIG5vdCB0
byBzZXQgdGhlIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgb3IgZXZlbiBzZXQgaXQgdG8g4oCYcmVw
bGFjZScgYW5kIHRoZSBzZXJ2ZXIgd291bGQgaGF2ZSB0byByZXNwb25kIHdpdGggYW4gb2suDQoN
Ck1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0
aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0K

--_000_A125E53CE190A749957C19483DC79F9F5CCC9DFBUS70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkkgZG9u4oCZdCB0aGluayBpdCB3b3VsZCBoZWxwIHRvIHNheSDigJxvbmx5IGlmIG5vIG90aGVy
IGNoaWxkIG5vZGVzIGV4aXN0IGluIHRoZSBzYW1lIHRyYW5zYWN0aW9u4oCdLiZuYnNwOyBUaG9z
ZSAyIHJlcXVlc3RzIHNob3VsZCB3b3JrIGV2ZW4gaWYgdGhlcmUgaXMgYSBjb21taXQgYWZ0ZXIN
CiBlYWNoIG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHdlIHNob3VsZCBpbnN0ZWFkIGNsYXJpZnkgdGhh
dCBhbiBlZGl0IHNob3VsZG7igJl0IGZhaWwgZHVlIHRvIGFuIGFic2VudCBOUC1jb250YWluZXIg
PyZuYnNwOyAoaS5lLiBhYnNlbmNlL3ByZXNlbmNlIG9mIGFuIE5QLWNvbnRhaW5lciBzaG91bGQg
YmUg4oCcbW9vdOKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFoZXNoIEpldGhhbmFuZGFuaSBb
bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz
ZGF5LCBKdWx5IDE0LCAyMDE2IDE2OjAwPGJyPg0KPGI+VG86PC9iPiBBbmR5IEJpZXJtYW48YnI+
DQo8Yj5DYzo8L2I+IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpOyBOZXRjb25mPGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gV2hhdCBzaG91bGQgYSBzZXJ2ZXIgcmVzcG9uc2Ug
YmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
SnVsIDE0LCAyMDE2LCBhdCAxMjoxNyBQTSwgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWls
dG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBZQU5HIHRleHQgc2F5cyBhIHNlcnZlciBNQVkgZGVsZXRl
IGFuIGVtcHR5IE5QIGNvbnRhaW5lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5V
c2luZyBkZWZhdWx0LW9wZXJhdGlvbj1ub25lIGltcGxpZXMgdGhhdCB0aGUgY2xpZW50IGlzIHN1
cmUgdGhlIG5vZGVzIGZvciBvcGVyYXRpb249bm9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPmFjdHVhbGx5IGV4aXN0LiZuYnNwOyBCZWNhdXNlIG9mIHRoaXMgWUFORyBkZXRhaWws
IHRoZSBjbGllbnQgY2Fubm90IGJlIHN1cmUgc28gdXNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5kZWZhdWx0LW9wZXJhdGlvbj1ub25lIG1heSBub3Qgd29yay48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGF0IHRvIG1lIGlzIHdoZXJlIHRoZSBkaXNjb25uZWN0IGxpZXMgYmV0d2Vl
biB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIuIFRoZSBjbGllbnQgaXMgYXNzdW1pbmcgdGhhdCB0aGUg
bm9kZXMgd2VyZSBjcmVhdGVkIGFzIHBhcnQgb2YgdGhlIGZpcnN0IHJlcXVlc3QsIHdoaWxlIHRo
ZSBzZXJ2ZXIgaXMg4oCcZGVsZXRpbmcmcXVvdDsgaXQgYmVjYXVzZSBpdCBpcyBhbiBlbXB0eSBO
UCBjb250YWluZXIuIENhbiB0aGUgdGV4dA0KIGJlIGNsYXJpZmllZCB0byBtYWtlIGl0IGNsZWFy
ZXI/IFNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgdGhhdCBhIE5QIGNvbnRhaW5lciBzaG91bGQg
YmUgZGVsZXRlZCBvbmx5IGlmIG5vIG90aGVyIGNoaWxkIG5vZGVzIGV4aXN0IGluIHRoZSBzYW1l
IHRyYW5zYWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5TZW1hbnRpY2FsbHksIGl0IHdvdWxkIGhhdmUgbWFkZSBubyBkaWZmZXJlbmNl
IHRvIHRoZSBvcGVyYXRpb24gaWYgdGhlIGNsaWVudCBkZWNpZGVkIG5vdCB0byBzZXQgdGhlIGRl
ZmF1bHQtb3BlcmF0aW9uPW5vbmUgb3IgZXZlbiBzZXQgaXQgdG8g4oCYcmVwbGFjZScgYW5kIHRo
ZSBzZXJ2ZXIgd291bGQgaGF2ZSB0byByZXNwb25kIHdpdGggYW4gb2suPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5k
YW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCC9DFBUS70TWXCHMBA11z_--


From nobody Thu Jul 14 13:30:24 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C712DAC5 for ; Thu, 14 Jul 2016 13:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gsf2jcEhw_Ah for ; Thu, 14 Jul 2016 13:30:19 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8B112DAB2 for ; Thu, 14 Jul 2016 13:30:18 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id EDB23F3C31B18; Thu, 14 Jul 2016 20:30:14 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6EKUHIB024482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 20:30:17 GMT
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6EKUHki020185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 20:30:17 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 16:30:17 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Andy Bierman 
Thread-Topic: [Netconf]  in a server that supports both writable-running and candidate
Thread-Index: AdHeAl/GLPvbP2zwTVylVCsJWBbO+AAIvxGAAAYCVGA=
Date: Thu, 14 Jul 2016 20:30:16 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC9EF3US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 20:30:22 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCC9EF3US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGh4IEFuZHkuICBCVFcgLT4gVGhpcyBpc27igJl0IGEgcHVyZWx5IGFjYWRlbWljIHF1ZXN0aW9u
LiAgTm9raWEgU1IgT1Mgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRh
dGUuICBBbmQgeWVzIGl0IGlzIGNvbXBsZXggdG8gbWFuYWdlLiAgVGhlIHR3byBkYXRhc3RvcmVz
IGNhbuKAmXQgYmUgc2ltcGx5IHRyZWF0ZWQgaW5kZXBlbmRlbnRseSBhbmQgc29tZSBsb2NraW5n
L2NvaGVyZW5jeSBtZWNoYW5pc21zIGFyZSBuZWVkZWQgYmV0d2VlbiB0aGVtLiAgIEJ1dCBJIHRo
aW5rIHNvbWUgb2YgdGhlIHNhbWUgY2hhbGxlbmdlcyBleGlzdCBmb3IgaW1wbGVtZW50YXRpb25z
IHRoYXQgZG8g4oCccHJpdmF0ZeKAnSBjYW5kaWRhdGVzIChpbiBDTEkgb3IgTkVUQ09ORikuDQoN
CkkgYWdyZWUgd2l0aCB0aGUgZGVhZGxvY2sgKHRoYXQgd2FzIG15IGxhc3QgcG9pbnQpLiAgVGhh
dCBpcyBvbmUgcmVhc29uIHdoeSBpdCBtYXkgbWFrZSBtb3JlIHNlbnNlIHRvIGltcGxpY2l0bHkg
Z3JhYiBib3RoIGxvY2tzIG9uIHRoZSBzZXJ2ZXIgc2lkZSB3aGVuIHRoZSAxc3Qgb25lIGlzIGFz
a2VkIGZvciAoaS5lLiByZWplY3QgdGhlIDJuZCBjbGllbnTigJlzIGxvY2sgcmVxdWVzdCkgaW5z
dGVhZCBvZiBsZWF2aW5nIHRoaXMgdG8gdGhlIGNsaWVudCBzaWRlLg0KDQpCdXQgZGVzcGl0ZSB0
aGUgY2hhbGxlbmdlcy9kaXNhc3RlciBkbyB5b3UgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgKGFuZCBt
YXkgYWxtb3N0IGJlIG5lY2Vzc2FyeSkgZm9yIHRoZSBzZXJ2ZXIgdG8gZWZmZWN0aXZlbHkgZ3Jh
bnQgYm90aCBsb2NrcyB3aGVuIGVpdGhlciBzaW5nbGUgb25lIGlzIHRha2VuID8NCg0KSmFzb24N
Cg0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBUaHVyc2RheSwgSnVseSAxNCwgMjAxNiAxNTox
NA0KVG86IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpDQpDYzogTmV0Y29uZg0KU3ViamVjdDog
UmU6IFtOZXRjb25mXSA8bG9jaz4gaW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoIHdyaXRh
YmxlLXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZQ0KDQpIaSwNCg0KSU1PIE5FVENPTkYgbG9ja3MgYXJl
IG5vdCB3ZWxsIGRlc2lnbmVkIGF0IGFsbC4NCkZvciBleGFtcGxlLCB5b3UgYXJlIG5vdCBldmVu
IGFsbG93ZWQgdG8gbG9jayBtdWx0aXBsZSBkYXRhc3RvcmVzIGF0IG9uY2UuDQpZb3UgYXJlIGZv
cmNlZCB0byBsb2NrIDEgYXQgYSB0aW1lLCBhbmQgaWYgMiBjbGllbnRzIGFyZSBkb2luZyB0aGlz
IGF0IHRoZSBzYW1lIHRpbWUsDQppdCBjYW4gbGVhZCB0byBhIGRlYWRsb2NrIGJldHdlZW4gdGhl
bSAoRWFjaCAxIGhvbGRpbmcgMSBsb2NrIHdhaXRpbmcgZm9yIHRoZSBvdGhlcikNCg0KVGhlIHNo
YXJlZCBjYW5kaWRhdGUgaXMgc29ydCBvZiBhIGRpc2FzdGVyIGJ1dCBpZiB5b3Ugd2FudCB0byB1
c2UgaXQNCnRoZW4geW91IHdpbGwgbmVlZCB0byBpbnZlbnQgeW91ciBvd24gImdpdCB1cGRhdGUi
LiAgVGhlIHJlYXNvbiBub2JvZHkgaW1wbGVtZW50cw0KOmNhbmRpZGF0ZSBhbmQgOndyaXRhYmxl
LXJ1bm5pbmcgdG9nZXRoZXIgaXMgYmVjYXVzZSB0aGVyZSBpcyBubyB3YXkgdG8gc3luY2gNCnRo
ZSBjYW5kaWRhdGUgaWYgcnVubmluZyBoYXMgYmVlbiBjaGFuZ2VkIHVuZGVybmVhdGggaXQuDQoN
CkEgY29uY3VycmVudCB3cml0ZSBkYXRhYmFzZSBpcyBub3QgImZpcnN0IHdyaXRlciB3aW5zLCBl
dmVyeWJvZHkgZWxzZSBibG93cyB1cCIuDQoNCg0KQW5keQ0KDQoNCg0KT24gVGh1LCBKdWwgMTQs
IDIwMTYgYXQgMTI6MDMgUE0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIDxqYXNvbi5zdGVy
bmVAbm9raWEuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tPj4gd3JvdGU6DQpIaSBh
bGwsDQoNCknigJltIGxvb2tpbmcgZm9yIG9waW5pb25zIG9uIGhvdyBhIGNsaWVudCAmIHNlcnZl
ciBtaWdodCBpbnRlcmFjdCBmb3IgdGhlIDxsb2NrPiBSUEMgd2hlbiBhIHNlcnZlciBzdXBwb3J0
cyBib3RoIHdyaXRhYmxlLXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZSBEUy4NCg0KSSBzdXNwZWN0IHRo
aXMgaXMgYW4gdW51c3VhbCBzaXR1YXRpb24gLT4gZG9lcyBhbnlvbmUgb3V0IHRoZXJlIHdvcmsg
d2l0aCBvciBoYXZlIGEgc2VydmVyIGltcGxlbWVudGF0aW9uIHRoYXQgc3VwcG9ydHMgYm90aCA/
DQoNClRoZSBzcGlyaXQgb2YgYSA8bG9jaz4gaXMgdG8gcmVzZXJ2ZSBleGNsdXNpdmUgYWNjZXNz
IHRvIGFsdGVyIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBkZXZpY2UsIGFuZCB0byBwcmV2ZW50
IG90aGVyIGNsaWVudHMgKG9yIG1hbmFnZW1lbnQgaW50ZXJmYWNlcykgZnJvbSBhbHRlcmluZyB0
aGUgY29uZmlnIGluIHRoZSBtZWFudGltZS4gIEkgcmVhbGl6ZSB0aGF0IGluIHRoZW9yeSB0aGUg
bG9ja3MgYXJlIOKAnHBlci1EU+KAnSAoaS5lLiBpbmRlcGVuZGFudCkgYnV0IEkgdGhpbmsgdGhh
dCBtaWdodCBiZSB0b28gc2ltcGxpc3RpYyBmb3IgYSBzeXN0ZW0gd2l0aCBib3RoIHdyaXRhYmxl
LXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZS4NCg0KSW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3Ro
IHdyaXRhYmxlLXJ1bm5pbmcgJiBjYW5kaWRhdGUsIGl0IHNlZW1zIHRvIG1ha2Ugc2Vuc2UgdGhh
dCBhIDxsb2NrPiBvZiB0aGUgcnVubmluZyBEUyB3b3VsZCBhbHNvIGNhdXNlIHRoZSBzZXJ2ZXIg
dG8gaW1wbGljaXRseSBsb2NrIHRoZSBjYW5kaWRhdGUgKG9yIGF0IGxlYXN0IHJlamVjdCBhIGxv
Y2sgcmVxdWVzdCBvZiB0aGUgY2FuZGlkYXRlKS4gIE90aGVyd2lzZSAoaS5lLiBhY2NlcHRpbmcg
YSBzdWJzZXF1ZW50IGxvY2sgb2YgdGhlIGNhbmRpZGF0ZSkgdGhlIGNsaWVudCBtYXkgYXNzdW1l
IHNpbmNlIGl0IGhhcyB0aGUgY2FuZGlkYXRlIGxvY2sgdGhlbiBpdCBoYXMgdGhlIGV4Y2x1c2l2
ZSByaWdodHMgdG8gdGhlIGNvbmZpZyBhbmQgY2FuIGhhcHBpbHkgZWRpdCAmIGNvbW1pdCB0aGUg
Y29uZmlnLiAgSXQgd291bGQgYmUgY29uZnVzaW5nIHRvIGVycm9yIG9uIHRoZSBjb21taXQgKGR1
ZSB0byBsb2NraW5nKSBhZnRlciBoYXZpbmcgYWNjZXB0ZWQgYSBsb2NrLg0KDQpTaW1pbGFybHkg
Zm9yIHRoZSByZXZlcnNlIHNpdHVhdGlvbiAtPiBpZiBhIGNsaWVudCB0YWtlcyBhIGNhbmRpZGF0
ZSA8bG9jaz4gdGhlbiBjb3VsZG7igJl0IGl0IGFzc3VtZSB0aGF0IG5vYm9keSBjYW4gc3Vic2Vx
dWVudGx5IGJsb2NrIHRoZWlyIGNvbW1pdCBieSB0YWtpbmcgYSBsb2NrIG9mIHRoZSBydW5uaW5n
IERTID8NCg0KSXQgc2VlbXMgbGlrZSB0aGUgc2VydmVyIHNob3VsZCBtYW5hZ2UgdGhpcyBpbnRl
cmFjdGlvbiBhbmQgYXZvaWQgZ2l2aW5nIGFuIOKAnE9L4oCdIHRvIGNsaWVudHMgdGFraW5nIHRo
ZSB0d28gbG9ja3Mgb24gdGhlIHR3byBkYXRhc3RvcmVzLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCB0
aGlzIGNvdWxkIGFsbCBiZSBsZWZ0IHVwIHRvIHRoZSBjbGllbnRzIHRvIGRlYWwgd2l0aC4gIENs
aWVudHMgd291bGQgaGF2ZSB0byBzZWUgdGhhdCBhIHNlcnZlciBoYXMgYm90aCBhIHdyaXRlYWJs
ZS1ydW5uaW5nIGFuZCBhIGNhbmRpZGF0ZSBEUyBhbmQgdGFrZSBhIGxvY2sgb2YgYm90aC4gICBC
dXQgdGhhdCB3b3VsZCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIGhhdmUgdGhhdCBiZWhhdmlvciAo
aW5zdGVhZCBvZiB0aGUgc2VydmVyIHRoYXQgc3VwcG9ydHMgdGhlIDIgRFNlcyBkZWFsaW5nIHdp
dGggdGhpcykuICBJdCBhbHNvIGhhcyByYWNlIGNvbmRpdGlvbnMgd2hlcmUgdGhlIGNsaWVudCB0
YWtlcyAxIGxvY2sgYnV0IHNvbWVvbmUgZWxzZSBnZXRzIHRoZSBzZWNvbmQgbG9jay4NCg0KT3Bp
bmlvbnMgYXBwcmVjaWF0ZWQuDQpSZWdhcmRzLA0KSmFzb24NCg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5l
dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K

--_000_A125E53CE190A749957C19483DC79F9F5CCC9EF3US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHggQW5keS4mbmJzcDsgQlRXIC0mZ3Q7IFRoaXMgaXNu
4oCZdCBhIHB1cmVseSBhY2FkZW1pYyBxdWVzdGlvbi4mbmJzcDsgTm9raWEgU1IgT1Mgc3VwcG9y
dHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUuJm5ic3A7IEFuZCB5ZXMgaXQg
aXMgY29tcGxleCB0byBtYW5hZ2UuJm5ic3A7IFRoZSB0d28NCiBkYXRhc3RvcmVzIGNhbuKAmXQg
YmUgc2ltcGx5IHRyZWF0ZWQgaW5kZXBlbmRlbnRseSBhbmQgc29tZSBsb2NraW5nL2NvaGVyZW5j
eSBtZWNoYW5pc21zIGFyZSBuZWVkZWQgYmV0d2VlbiB0aGVtLiZuYnNwOyZuYnNwOyBCdXQgSSB0
aGluayBzb21lIG9mIHRoZSBzYW1lIGNoYWxsZW5nZXMgZXhpc3QgZm9yIGltcGxlbWVudGF0aW9u
cyB0aGF0IGRvIOKAnHByaXZhdGXigJ0gY2FuZGlkYXRlcyAoaW4gQ0xJIG9yIE5FVENPTkYpLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHRoZSBkZWFkbG9jayAodGhhdCB3YXMgbXkgbGFzdCBwb2lu
dCkuJm5ic3A7IFRoYXQgaXMgb25lIHJlYXNvbiB3aHkgaXQgbWF5IG1ha2UgbW9yZSBzZW5zZSB0
byBpbXBsaWNpdGx5IGdyYWIgYm90aCBsb2NrcyBvbiB0aGUgc2VydmVyIHNpZGUgd2hlbiB0aGUN
CiAxPHN1cD5zdDwvc3VwPiBvbmUgaXMgYXNrZWQgZm9yIChpLmUuIHJlamVjdCB0aGUgMjxzdXA+
bmQ8L3N1cD4gY2xpZW504oCZcyBsb2NrIHJlcXVlc3QpIGluc3RlYWQgb2YgbGVhdmluZyB0aGlz
IHRvIHRoZSBjbGllbnQgc2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBkZXNwaXRlIHRoZSBjaGFsbGVuZ2Vz
L2Rpc2FzdGVyIGRvIHlvdSB0aGluayBpdCBtYWtlcyBzZW5zZSAoYW5kIG1heSBhbG1vc3QgYmUg
bmVjZXNzYXJ5KSBmb3IgdGhlIHNlcnZlciB0byBlZmZlY3RpdmVseSBncmFudCBib3RoIGxvY2tz
IHdoZW4gZWl0aGVyIHNpbmdsZQ0KIG9uZSBpcyB0YWtlbiA/PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYXNvbjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5ldGNvbmYgW21h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkg
Qmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxNCwgMjAxNiAxNToxNDxi
cj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSk8YnI+DQo8Yj5DYzo8L2I+
IE5ldGNvbmY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSAmbHQ7bG9jayZndDsg
aW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoIHdyaXRhYmxlLXJ1bm5pbmcgYW5kIGNhbmRp
ZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gTkVUQ09ORiBs
b2NrcyBhcmUgbm90IHdlbGwgZGVzaWduZWQgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIHlvdSBhcmUgbm90IGV2
ZW4gYWxsb3dlZCB0byBsb2NrIG11bHRpcGxlIGRhdGFzdG9yZXMgYXQgb25jZS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgZm9yY2Vk
IHRvIGxvY2sgMSBhdCBhIHRpbWUsIGFuZCBpZiAyIGNsaWVudHMgYXJlIGRvaW5nIHRoaXMgYXQg
dGhlIHNhbWUgdGltZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPml0IGNhbiBsZWFkIHRvIGEgZGVhZGxvY2sgYmV0d2VlbiB0aGVtIChFYWNoIDEg
aG9sZGluZyAxIGxvY2sgd2FpdGluZyBmb3IgdGhlIG90aGVyKTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2hhcmVkIGNhbmRpZGF0ZSBp
cyBzb3J0IG9mIGEgZGlzYXN0ZXIgYnV0IGlmIHlvdSB3YW50IHRvIHVzZSBpdDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlbiB5b3Ugd2lsbCBu
ZWVkIHRvIGludmVudCB5b3VyIG93biAmcXVvdDtnaXQgdXBkYXRlJnF1b3Q7LiZuYnNwOyBUaGUg
cmVhc29uIG5vYm9keSBpbXBsZW1lbnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj46Y2FuZGlkYXRlIGFuZCA6d3JpdGFibGUtcnVubmluZyB0b2dl
dGhlciBpcyBiZWNhdXNlIHRoZXJlIGlzIG5vIHdheSB0byBzeW5jaDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGNhbmRpZGF0ZSBpZiBydW5u
aW5nIGhhcyBiZWVuIGNoYW5nZWQgdW5kZXJuZWF0aCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjb25jdXJyZW50IHdyaXRlIGRhdGFi
YXNlIGlzIG5vdCAmcXVvdDtmaXJzdCB3cml0ZXIgd2lucywgZXZlcnlib2R5IGVsc2UgYmxvd3Mg
dXAmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMTQsIDIwMTYgYXQgMTI6MDMgUE0sIFN0ZXJuZSwg
SmFzb24gKE5va2lhIC0gQ0EpICZsdDs8YSBocmVmPSJtYWlsdG86amFzb24uc3Rlcm5lQG5va2lh
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphc29uLnN0ZXJuZUBub2tpYS5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPknigJltIGxvb2tp
bmcgZm9yIG9waW5pb25zIG9uIGhvdyBhIGNsaWVudCAmYW1wOyBzZXJ2ZXIgbWlnaHQgaW50ZXJh
Y3QgZm9yIHRoZSAmbHQ7bG9jayZndDsgUlBDIHdoZW4gYSBzZXJ2ZXIgc3VwcG9ydHMgYm90aCB3
cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUgRFMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBz
dXNwZWN0IHRoaXMgaXMgYW4gdW51c3VhbCBzaXR1YXRpb24gLSZndDsgZG9lcyBhbnlvbmUgb3V0
IHRoZXJlIHdvcmsgd2l0aCBvciBoYXZlIGEgc2VydmVyIGltcGxlbWVudGF0aW9uIHRoYXQgc3Vw
cG9ydHMgYm90aCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBzcGlyaXQgb2YgYSAmbHQ7bG9jayZndDsgaXMg
dG8gcmVzZXJ2ZSBleGNsdXNpdmUgYWNjZXNzIHRvIGFsdGVyIHRoZSBjb25maWd1cmF0aW9uIG9m
IHRoZSBkZXZpY2UsIGFuZCB0byBwcmV2ZW50IG90aGVyIGNsaWVudHMgKG9yIG1hbmFnZW1lbnQg
aW50ZXJmYWNlcykgZnJvbSBhbHRlcmluZyB0aGUNCiBjb25maWcgaW4gdGhlIG1lYW50aW1lLiZu
YnNwOyBJIHJlYWxpemUgdGhhdCBpbiB0aGVvcnkgdGhlIGxvY2tzIGFyZSDigJxwZXItRFPigJ0g
KGkuZS4gaW5kZXBlbmRhbnQpIGJ1dCBJIHRoaW5rIHRoYXQgbWlnaHQgYmUgdG9vIHNpbXBsaXN0
aWMgZm9yIGEgc3lzdGVtIHdpdGggYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkluIGEgc2VydmVyIHRoYXQgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5u
aW5nICZhbXA7IGNhbmRpZGF0ZSwgaXQgc2VlbXMgdG8gbWFrZSBzZW5zZSB0aGF0IGEgJmx0O2xv
Y2smZ3Q7IG9mIHRoZSBydW5uaW5nIERTIHdvdWxkIGFsc28gY2F1c2UgdGhlIHNlcnZlciB0byBp
bXBsaWNpdGx5IGxvY2sgdGhlIGNhbmRpZGF0ZQ0KIChvciBhdCBsZWFzdCByZWplY3QgYSBsb2Nr
IHJlcXVlc3Qgb2YgdGhlIGNhbmRpZGF0ZSkuJm5ic3A7IE90aGVyd2lzZSAoaS5lLiBhY2NlcHRp
bmcgYSBzdWJzZXF1ZW50IGxvY2sgb2YgdGhlIGNhbmRpZGF0ZSkgdGhlIGNsaWVudCBtYXkgYXNz
dW1lIHNpbmNlIGl0IGhhcyB0aGUgY2FuZGlkYXRlIGxvY2sgdGhlbiBpdCBoYXMgdGhlIGV4Y2x1
c2l2ZSByaWdodHMgdG8gdGhlIGNvbmZpZyBhbmQgY2FuIGhhcHBpbHkgZWRpdCAmYW1wOyBjb21t
aXQgdGhlIGNvbmZpZy4mbmJzcDsNCiBJdCB3b3VsZCBiZSBjb25mdXNpbmcgdG8gZXJyb3Igb24g
dGhlIGNvbW1pdCAoZHVlIHRvIGxvY2tpbmcpIGFmdGVyIGhhdmluZyBhY2NlcHRlZCBhIGxvY2su
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPlNpbWlsYXJseSBmb3IgdGhlIHJldmVyc2Ugc2l0dWF0aW9uIC0mZ3Q7IGlm
IGEgY2xpZW50IHRha2VzIGEgY2FuZGlkYXRlICZsdDtsb2NrJmd0OyB0aGVuIGNvdWxkbuKAmXQg
aXQgYXNzdW1lIHRoYXQgbm9ib2R5IGNhbiBzdWJzZXF1ZW50bHkgYmxvY2sgdGhlaXIgY29tbWl0
IGJ5IHRha2luZyBhIGxvY2sgb2YgdGhlDQogcnVubmluZyBEUyA/PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IHNl
ZW1zIGxpa2UgdGhlIHNlcnZlciBzaG91bGQgbWFuYWdlIHRoaXMgaW50ZXJhY3Rpb24gYW5kIGF2
b2lkIGdpdmluZyBhbiDigJxPS+KAnSB0byBjbGllbnRzIHRha2luZyB0aGUgdHdvIGxvY2tzIG9u
IHRoZSB0d28gZGF0YXN0b3Jlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gdGhlIG90aGVyIGhhbmQgdGhpcyBj
b3VsZCBhbGwgYmUgbGVmdCB1cCB0byB0aGUgY2xpZW50cyB0byBkZWFsIHdpdGguJm5ic3A7IENs
aWVudHMgd291bGQgaGF2ZSB0byBzZWUgdGhhdCBhIHNlcnZlciBoYXMgYm90aCBhIHdyaXRlYWJs
ZS1ydW5uaW5nIGFuZCBhIGNhbmRpZGF0ZSBEUyBhbmQgdGFrZQ0KIGEgbG9jayBvZiBib3RoLiZu
YnNwOyZuYnNwOyBCdXQgdGhhdCB3b3VsZCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIGhhdmUgdGhh
dCBiZWhhdmlvciAoaW5zdGVhZCBvZiB0aGUgc2VydmVyIHRoYXQgc3VwcG9ydHMgdGhlIDIgRFNl
cyBkZWFsaW5nIHdpdGggdGhpcykuJm5ic3A7IEl0IGFsc28gaGFzIHJhY2UgY29uZGl0aW9ucyB3
aGVyZSB0aGUgY2xpZW50IHRha2VzIDEgbG9jayBidXQgc29tZW9uZSBlbHNlIGdldHMgdGhlIHNl
Y29uZCBsb2NrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PcGluaW9ucyBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5KYXNvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl
Zj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCC9EF3US70TWXCHMBA11z_--


From nobody Thu Jul 14 13:34:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6890012DAF4 for ; Thu, 14 Jul 2016 13:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iCFz_x_xuh8n for ; Thu, 14 Jul 2016 13:34:06 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA6F12D5BE for ; Thu, 14 Jul 2016 13:34:06 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 7F77F439F7251; Thu, 14 Jul 2016 20:34:02 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6EKY5Fs019563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 20:34:05 GMT
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6EKY5nC028355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 20:34:05 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 16:34:05 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Mahesh Jethanandani 
Thread-Topic: [Netconf]  in a server that supports both writable-running and candidate
Thread-Index: AdHeAl/GLPvbP2zwTVylVCsJWBbO+AAKYmOAAAeySJA=
Date: Thu, 14 Jul 2016 20:34:04 +0000
Message-ID: 
References:  <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com>
In-Reply-To: <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCC9F14US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 20:34:09 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCC9F14US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTWFoZXNoLA0KDQpJ4oCZbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgeW91ciBmaXJzdCBzdGF0
ZW1lbnQuICBDYW4geW91IGV4cGxhaW4gZnVydGhlciA/ICBBcmUgeW91IHNheWluZyB0aGF0IG9u
IGEgc3lzdGVtIHRoYXQgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRh
dGUgeW91IHRoaW5rIGNsaWVudHMgbWF5IGp1c3QgdGFrZSB0aGUgbG9jayBvbiB0aGUgY2FuZGlk
YXRlLCBkbyB0aGVpciB1cGRhdGVkLCBjb21taXQgYW5kIHRoZW4gcmVsZWFzZSB0aGUgbG9jayA/
ICAgSSB0aGluayB0aGF0IGlzIHJlYXNvbmFibGUvcG9zc2libGUuDQoNCkFzIGZvciBwcmV2ZW50
aW5nIG90aGVyIG1nbW50LiBpbnRlcmZhY2VzIGZyb20gaW50ZXJmZXJpbmcgLT4gSSB0aGluayBS
RkM2MjQxIGlzIHJlYXNvbmFibHkgY2xlYXIgdGhhdCBzaG91bGQgYmUgcHJldmVudGVkOg0KDQpB
ZGRpdGlvbmFsbHksIHRoZSBzeXN0ZW0NCiAgICAgIHdpbGwgZW5zdXJlIHRoYXQgdGhlc2UgbG9j
a2VkIGNvbmZpZ3VyYXRpb24gcmVzb3VyY2VzIHdpbGwgbm90IGJlDQogICAgICBtb2RpZmllZCBi
eSBvdGhlciBub24tTkVUQ09ORiBtYW5hZ2VtZW50IG9wZXJhdGlvbnMgc3VjaCBhcyBTTk1QDQog
ICAgICBhbmQgQ0xJLg0KDQpJIGFncmVlIHdpdGggdGhlIGdlbmVyYWwgd29ya2Zsb3cgYnV0IHRo
ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBjbGllbnQgc2hvdWxkIGV4cGxpY2l0bHkgZ2V0IGJv
dGggbG9ja3MsIG9yIHdoZXRoZXIgdGhlIHNlcnZlciBzaWRlIHNob3VsZCBpbXBsaWNpdGx5IHRh
a2UgYm90aCBsb2NrcyAoaS5lLiBwcmV2ZW50IHNlcGFyYXRlIG1vZGlmaWNhdGlvbnMvbG9jayBv
ZiB0aGUgb3RoZXIgRFMpLiAgSXQgaXNu4oCZdCBvYnZpb3VzIGJ1dCBJIGxlYW4gdG93YXJkcyB0
aGUgc2VydmVyIHNpZGUgaGFuZGxpbmcgdGhpcyBzaXR1YXRpb24gKGVzcGVjaWFsbHkgc2luY2Ug
dGhlIGNvbWJpbmF0aW9uIG9mIHdyaXRlYWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUgc3VwcG9y
dCBpcyBzb21ld2hhdCByYXJlKS4NCg0KSmFzb24NCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFu
aSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bHkg
MTQsIDIwMTYgMTY6MDENClRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKQ0KQ2M6IE5ldGNv
bmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gPGxvY2s+IGluIGEgc2VydmVyIHRoYXQgc3VwcG9y
dHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUNCg0KSSBzZWUgY2xpZW50cyBh
Y3F1aXJpbmcgbG9jayBvbiB0aGUgY2FuZGlkYXRlIGNvbmZpZyBidXQgbm90IG9uIHJ1bm5pbmcu
IFlvdSBhcmUgcmlnaHQgdGhhdCBpdCBkb2VzIG5vdCBwcmV2ZW50LCBzYXkgUkVTVENPTkYgb3Ig
ZXZlbiBDTEkgZnJvbSB1cGRhdGluZyB0aGUgcnVubmluZy1jb25maWcgZGlyZWN0bHkuDQoNCkEg
d29ya2Zsb3cgZm9yIHdoYXQgc2hvdWxkIGJlIGhhcHBlbmluZyBpczoNCg0KLSBhY3F1aXJlIGxv
Y2sgb24gY2FuZGlkYXRlIGFuZCBydW5uaW5nIChjYW4gY3JlYXRlIGRlYWRsb2NrIGFzIEFuZHkg
bWVudGlvbnMpDQotIGVkaXQgdGhlIGNhbmRpZGF0ZSBjb25maWcNCi0gdmFsaWRhdGUgY2FuZGlk
YXRlIGNvbmZpZw0KLSBjb21taXQgY2FuZGlkYXRlIHRvIHJ1bm5pbmcNCi0gcmVsZWFzZSBsb2Nr
IG9uIGNhbmRpZGF0ZSBhbmQgcnVubmluZw0KDQoNCk9uIEp1bCAxNCwgMjAxNiwgYXQgMTI6MDMg
UE0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPG1h
aWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tPj4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KSeKAmW0g
bG9va2luZyBmb3Igb3BpbmlvbnMgb24gaG93IGEgY2xpZW50ICYgc2VydmVyIG1pZ2h0IGludGVy
YWN0IGZvciB0aGUgPGxvY2s+IFJQQyB3aGVuIGEgc2VydmVyIHN1cHBvcnRzIGJvdGggd3JpdGFi
bGUtcnVubmluZyBhbmQgY2FuZGlkYXRlIERTLg0KDQpJIHN1c3BlY3QgdGhpcyBpcyBhbiB1bnVz
dWFsIHNpdHVhdGlvbiAtPiBkb2VzIGFueW9uZSBvdXQgdGhlcmUgd29yayB3aXRoIG9yIGhhdmUg
YSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBib3RoID8NCg0KVGhlIHNwaXJp
dCBvZiBhIDxsb2NrPiBpcyB0byByZXNlcnZlIGV4Y2x1c2l2ZSBhY2Nlc3MgdG8gYWx0ZXIgdGhl
IGNvbmZpZ3VyYXRpb24gb2YgdGhlIGRldmljZSwgYW5kIHRvIHByZXZlbnQgb3RoZXIgY2xpZW50
cyAob3IgbWFuYWdlbWVudCBpbnRlcmZhY2VzKSBmcm9tIGFsdGVyaW5nIHRoZSBjb25maWcgaW4g
dGhlIG1lYW50aW1lLiAgSSByZWFsaXplIHRoYXQgaW4gdGhlb3J5IHRoZSBsb2NrcyBhcmUg4oCc
cGVyLURT4oCdIChpLmUuIGluZGVwZW5kYW50KSBidXQgSSB0aGluayB0aGF0IG1pZ2h0IGJlIHRv
byBzaW1wbGlzdGljIGZvciBhIHN5c3RlbSB3aXRoIGJvdGggd3JpdGFibGUtcnVubmluZyBhbmQg
Y2FuZGlkYXRlLg0KDQpJbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIGJvdGggd3JpdGFibGUtcnVu
bmluZyAmIGNhbmRpZGF0ZSwgaXQgc2VlbXMgdG8gbWFrZSBzZW5zZSB0aGF0IGEgPGxvY2s+IG9m
IHRoZSBydW5uaW5nIERTIHdvdWxkIGFsc28gY2F1c2UgdGhlIHNlcnZlciB0byBpbXBsaWNpdGx5
IGxvY2sgdGhlIGNhbmRpZGF0ZSAob3IgYXQgbGVhc3QgcmVqZWN0IGEgbG9jayByZXF1ZXN0IG9m
IHRoZSBjYW5kaWRhdGUpLiAgT3RoZXJ3aXNlIChpLmUuIGFjY2VwdGluZyBhIHN1YnNlcXVlbnQg
bG9jayBvZiB0aGUgY2FuZGlkYXRlKSB0aGUgY2xpZW50IG1heSBhc3N1bWUgc2luY2UgaXQgaGFz
IHRoZSBjYW5kaWRhdGUgbG9jayB0aGVuIGl0IGhhcyB0aGUgZXhjbHVzaXZlIHJpZ2h0cyB0byB0
aGUgY29uZmlnIGFuZCBjYW4gaGFwcGlseSBlZGl0ICYgY29tbWl0IHRoZSBjb25maWcuICBJdCB3
b3VsZCBiZSBjb25mdXNpbmcgdG8gZXJyb3Igb24gdGhlIGNvbW1pdCAoZHVlIHRvIGxvY2tpbmcp
IGFmdGVyIGhhdmluZyBhY2NlcHRlZCBhIGxvY2suDQoNClNpbWlsYXJseSBmb3IgdGhlIHJldmVy
c2Ugc2l0dWF0aW9uIC0+IGlmIGEgY2xpZW50IHRha2VzIGEgY2FuZGlkYXRlIDxsb2NrPiB0aGVu
IGNvdWxkbuKAmXQgaXQgYXNzdW1lIHRoYXQgbm9ib2R5IGNhbiBzdWJzZXF1ZW50bHkgYmxvY2sg
dGhlaXIgY29tbWl0IGJ5IHRha2luZyBhIGxvY2sgb2YgdGhlIHJ1bm5pbmcgRFMgPw0KDQpJdCBz
ZWVtcyBsaWtlIHRoZSBzZXJ2ZXIgc2hvdWxkIG1hbmFnZSB0aGlzIGludGVyYWN0aW9uIGFuZCBh
dm9pZCBnaXZpbmcgYW4g4oCcT0vigJ0gdG8gY2xpZW50cyB0YWtpbmcgdGhlIHR3byBsb2NrcyBv
biB0aGUgdHdvIGRhdGFzdG9yZXMuDQoNCk9uIHRoZSBvdGhlciBoYW5kIHRoaXMgY291bGQgYWxs
IGJlIGxlZnQgdXAgdG8gdGhlIGNsaWVudHMgdG8gZGVhbCB3aXRoLiAgQ2xpZW50cyB3b3VsZCBo
YXZlIHRvIHNlZSB0aGF0IGEgc2VydmVyIGhhcyBib3RoIGEgd3JpdGVhYmxlLXJ1bm5pbmcgYW5k
IGEgY2FuZGlkYXRlIERTIGFuZCB0YWtlIGEgbG9jayBvZiBib3RoLiAgIEJ1dCB0aGF0IHdvdWxk
IHJlcXVpcmUgYWxsIGNsaWVudHMgdG8gaGF2ZSB0aGF0IGJlaGF2aW9yIChpbnN0ZWFkIG9mIHRo
ZSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyB0aGUgMiBEU2VzIGRlYWxpbmcgd2l0aCB0aGlzKS4gIEl0
IGFsc28gaGFzIHJhY2UgY29uZGl0aW9ucyB3aGVyZSB0aGUgY2xpZW50IHRha2VzIDEgbG9jayBi
dXQgc29tZW9uZSBlbHNlIGdldHMgdGhlIHNlY29uZCBsb2NrLg0KDQpPcGluaW9ucyBhcHByZWNp
YXRlZC4NClJlZ2FyZHMsDQpKYXNvbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8
bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldGNvbmYNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFp
bC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KDQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCC9F14US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw
cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5IaSBNYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSBub3Qgc3VyZSBJIHVuZGVy
c3RhbmQgeW91ciBmaXJzdCBzdGF0ZW1lbnQuJm5ic3A7IENhbiB5b3UgZXhwbGFpbiBmdXJ0aGVy
ID8mbmJzcDsgQXJlIHlvdSBzYXlpbmcgdGhhdCBvbiBhIHN5c3RlbSB0aGF0IHN1cHBvcnRzIGJv
dGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlDQogeW91IHRoaW5rIGNsaWVudHMgbWF5
IGp1c3QgdGFrZSB0aGUgbG9jayBvbiB0aGUgY2FuZGlkYXRlLCBkbyB0aGVpciB1cGRhdGVkLCBj
b21taXQgYW5kIHRoZW4gcmVsZWFzZSB0aGUgbG9jayA/Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhh
dCBpcyByZWFzb25hYmxlL3Bvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgZm9yIHByZXZlbnRpbmcgb3Ro
ZXIgbWdtbnQuIGludGVyZmFjZXMgZnJvbSBpbnRlcmZlcmluZyAtJmd0OyBJIHRoaW5rIFJGQzYy
NDEgaXMgcmVhc29uYWJseSBjbGVhciB0aGF0IHNob3VsZCBiZSBwcmV2ZW50ZWQ6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRkaXRpb25hbGx5LCB0aGUgc3lzdGVtPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2lsbCBlbnN1cmUgdGhhdCB0aGVzZSBsb2NrZWQgY29u
ZmlndXJhdGlvbiByZXNvdXJjZXMgd2lsbCBub3QgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBtb2RpZmllZCBieSBvdGhlciBub24tTkVUQ09ORiBtYW5hZ2VtZW50IG9wZXJhdGlvbnMg
c3VjaCBhcyBTTk1QPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIENMSS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgYWdyZWUgd2l0aCB0aGUgZ2VuZXJhbCB3b3JrZmxvdyBidXQgdGhlIHF1ZXN0aW9uIGlz
IHdoZXRoZXIgdGhlIGNsaWVudCBzaG91bGQgZXhwbGljaXRseSBnZXQgYm90aCBsb2Nrcywgb3Ig
d2hldGhlciB0aGUgc2VydmVyIHNpZGUgc2hvdWxkIGltcGxpY2l0bHkgdGFrZQ0KIGJvdGggbG9j
a3MgKGkuZS4gcHJldmVudCBzZXBhcmF0ZSBtb2RpZmljYXRpb25zL2xvY2sgb2YgdGhlIG90aGVy
IERTKS4mbmJzcDsgSXQgaXNu4oCZdCBvYnZpb3VzIGJ1dCBJIGxlYW4gdG93YXJkcyB0aGUgc2Vy
dmVyIHNpZGUgaGFuZGxpbmcgdGhpcyBzaXR1YXRpb24gKGVzcGVjaWFsbHkgc2luY2UgdGhlIGNv
bWJpbmF0aW9uIG9mIHdyaXRlYWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUgc3VwcG9ydCBpcyBz
b21ld2hhdCByYXJlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFoZXNo
IEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+
U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDE0LCAyMDE2IDE2OjAxPGJyPg0KPGI+VG86PC9iPiBT
dGVybmUsIEphc29uIChOb2tpYSAtIENBKTxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZjxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdICZsdDtsb2NrJmd0OyBpbiBhIHNlcnZlciB0aGF0
IHN1cHBvcnRzIGJvdGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIGNsaWVudHMg
YWNxdWlyaW5nIGxvY2sgb24gdGhlIGNhbmRpZGF0ZSBjb25maWcgYnV0IG5vdCBvbiBydW5uaW5n
LiBZb3UgYXJlIHJpZ2h0IHRoYXQgaXQgZG9lcyBub3QgcHJldmVudCwgc2F5IFJFU1RDT05GIG9y
IGV2ZW4gQ0xJIGZyb20gdXBkYXRpbmcgdGhlIHJ1bm5pbmctY29uZmlnIGRpcmVjdGx5LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHdvcmtm
bG93IGZvciB3aGF0IHNob3VsZCBiZSBoYXBwZW5pbmcgaXM6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gYWNxdWlyZSBsb2NrIG9uIGNhbmRp
ZGF0ZSBhbmQgcnVubmluZyAoY2FuIGNyZWF0ZSBkZWFkbG9jayBhcyBBbmR5IG1lbnRpb25zKTxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBlZGl0
IHRoZSBjYW5kaWRhdGUgY29uZmlnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4tIHZhbGlkYXRlIGNhbmRpZGF0ZSBjb25maWc8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gY29tbWl0IGNhbmRpZGF0
ZSB0byBydW5uaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4tIHJlbGVhc2UgbG9jayBvbiBjYW5kaWRhdGUgYW5kIHJ1bm5pbmc8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAxNCwgMjAxNiwg
YXQgMTI6MDMgUE0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpICZsdDs8YSBocmVmPSJtYWls
dG86amFzb24uc3Rlcm5lQG5va2lhLmNvbSI+amFzb24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPknigJltIGxvb2tp
bmcgZm9yIG9waW5pb25zIG9uIGhvdyBhIGNsaWVudCAmYW1wOyBzZXJ2ZXIgbWlnaHQgaW50ZXJh
Y3QgZm9yIHRoZSAmbHQ7bG9jayZndDsgUlBDIHdoZW4gYSBzZXJ2ZXIgc3VwcG9ydHMgYm90aCB3
cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUgRFMuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHN1c3BlY3QgdGhp
cyBpcyBhbiB1bnVzdWFsIHNpdHVhdGlvbiAtJmd0OyBkb2VzIGFueW9uZSBvdXQgdGhlcmUgd29y
ayB3aXRoIG9yIGhhdmUgYSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBib3Ro
ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+VGhlIHNwaXJpdCBvZiBhICZsdDtsb2NrJmd0OyBpcyB0byByZXNlcnZl
IGV4Y2x1c2l2ZSBhY2Nlc3MgdG8gYWx0ZXIgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIGRldmlj
ZSwgYW5kIHRvIHByZXZlbnQgb3RoZXIgY2xpZW50cyAob3IgbWFuYWdlbWVudCBpbnRlcmZhY2Vz
KSBmcm9tIGFsdGVyaW5nIHRoZQ0KIGNvbmZpZyBpbiB0aGUgbWVhbnRpbWUuJm5ic3A7IEkgcmVh
bGl6ZSB0aGF0IGluIHRoZW9yeSB0aGUgbG9ja3MgYXJlIOKAnHBlci1EU+KAnSAoaS5lLiBpbmRl
cGVuZGFudCkgYnV0IEkgdGhpbmsgdGhhdCBtaWdodCBiZSB0b28gc2ltcGxpc3RpYyBmb3IgYSBz
eXN0ZW0gd2l0aCBib3RoIHdyaXRhYmxlLXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+SW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoIHdyaXRhYmxlLXJ1bm5pbmcgJmFtcDsg
Y2FuZGlkYXRlLCBpdCBzZWVtcyB0byBtYWtlIHNlbnNlIHRoYXQgYSAmbHQ7bG9jayZndDsgb2Yg
dGhlIHJ1bm5pbmcgRFMgd291bGQgYWxzbyBjYXVzZSB0aGUgc2VydmVyIHRvIGltcGxpY2l0bHkg
bG9jayB0aGUgY2FuZGlkYXRlDQogKG9yIGF0IGxlYXN0IHJlamVjdCBhIGxvY2sgcmVxdWVzdCBv
ZiB0aGUgY2FuZGlkYXRlKS4mbmJzcDsgT3RoZXJ3aXNlIChpLmUuIGFjY2VwdGluZyBhIHN1YnNl
cXVlbnQgbG9jayBvZiB0aGUgY2FuZGlkYXRlKSB0aGUgY2xpZW50IG1heSBhc3N1bWUgc2luY2Ug
aXQgaGFzIHRoZSBjYW5kaWRhdGUgbG9jayB0aGVuIGl0IGhhcyB0aGUgZXhjbHVzaXZlIHJpZ2h0
cyB0byB0aGUgY29uZmlnIGFuZCBjYW4gaGFwcGlseSBlZGl0ICZhbXA7IGNvbW1pdCB0aGUgY29u
ZmlnLiZuYnNwOw0KIEl0IHdvdWxkIGJlIGNvbmZ1c2luZyB0byBlcnJvciBvbiB0aGUgY29tbWl0
IChkdWUgdG8gbG9ja2luZykgYWZ0ZXIgaGF2aW5nIGFjY2VwdGVkIGEgbG9jay48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+U2ltaWxhcmx5IGZvciB0aGUgcmV2ZXJzZSBzaXR1YXRpb24gLSZndDsgaWYgYSBjbGllbnQg
dGFrZXMgYSBjYW5kaWRhdGUgJmx0O2xvY2smZ3Q7IHRoZW4gY291bGRu4oCZdCBpdCBhc3N1bWUg
dGhhdCBub2JvZHkgY2FuIHN1YnNlcXVlbnRseSBibG9jayB0aGVpciBjb21taXQgYnkgdGFraW5n
IGEgbG9jayBvZiB0aGUNCiBydW5uaW5nIERTID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQgc2VlbXMgbGlrZSB0
aGUgc2VydmVyIHNob3VsZCBtYW5hZ2UgdGhpcyBpbnRlcmFjdGlvbiBhbmQgYXZvaWQgZ2l2aW5n
IGFuIOKAnE9L4oCdIHRvIGNsaWVudHMgdGFraW5nIHRoZSB0d28gbG9ja3Mgb24gdGhlIHR3byBk
YXRhc3RvcmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiB0aGUgb3RoZXIgaGFuZCB0aGlzIGNvdWxkIGFsbCBi
ZSBsZWZ0IHVwIHRvIHRoZSBjbGllbnRzIHRvIGRlYWwgd2l0aC4mbmJzcDsgQ2xpZW50cyB3b3Vs
ZCBoYXZlIHRvIHNlZSB0aGF0IGEgc2VydmVyIGhhcyBib3RoIGEgd3JpdGVhYmxlLXJ1bm5pbmcg
YW5kIGEgY2FuZGlkYXRlIERTIGFuZCB0YWtlDQogYSBsb2NrIG9mIGJvdGguJm5ic3A7Jm5ic3A7
IEJ1dCB0aGF0IHdvdWxkIHJlcXVpcmUgYWxsIGNsaWVudHMgdG8gaGF2ZSB0aGF0IGJlaGF2aW9y
IChpbnN0ZWFkIG9mIHRoZSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyB0aGUgMiBEU2VzIGRlYWxpbmcg
d2l0aCB0aGlzKS4mbmJzcDsgSXQgYWxzbyBoYXMgcmFjZSBjb25kaXRpb25zIHdoZXJlIHRoZSBj
bGllbnQgdGFrZXMgMSBsb2NrIGJ1dCBzb21lb25lIGVsc2UgZ2V0cyB0aGUgc2Vjb25kIGxvY2su
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPk9waW5pb25zIGFwcHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphc29uPHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYg
bWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3Jn
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5OZXRjb25mQGlldGYub3JnPC9zcGFuPjwv
YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dGNvbmY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5p
QGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCC9F14US70TWXCHMBA11z_--


From nobody Thu Jul 14 14:13:07 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278C912D603 for ; Thu, 14 Jul 2016 14:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJLW0WF2L5Th for ; Thu, 14 Jul 2016 14:13:01 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870C012D82A for ; Thu, 14 Jul 2016 14:12:59 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id x130so129520955vkc.0 for ; Thu, 14 Jul 2016 14:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gZJK7lQw73lBPdS9PvZNu/rE6ARFGoSjxFB7JFAdwgc=; b=RuAuqK5C//+yk2hnRk4SgCb8c6A9W4ByDndM32SV5j2rYc1ppsDkF+HkAwRfdzXKCv UkvJSHR1dsliypIlymYSSqKAscHhDmI/rAib9vws1iAnwsL8F+5goYcxrUsJa9J8TAgk chj5W4NHXDd+hLEs58+QINYyWwnzSGvV8IA6r/AWBRB3wfkmBYYJ7Q/Lz6wT7d2ChAvw jcOjrswlLOPpYHBgmQWaGGv6UFxp5tzTaeK+8v7bNurJ9+B5uni5qlXnPXNcxaEPyIff MwKktn7ygYqnJREp3EomHFI7nLXC3/l4hKxS6nmKAnPH+dV0nvYl0xsYXCuZy+n2ImEJ sP/Q==
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; bh=gZJK7lQw73lBPdS9PvZNu/rE6ARFGoSjxFB7JFAdwgc=; b=XTlXs/Xe/Quc+Lqn4spdmrcrKrPxt5A1lv0L3DRi8eniN7G9+NrN7q4/gnNk1+fcX/ FGMWFK9l7YIUZWV4Emhkk0JTwX8Pqtxc+nafa6I1ckgsS6F2Un+tDYh1rjuEI/V+W0FX +AAjhzqHiQNdw8O5ZsJG3L0AUQ+uZRJzS7MZ3JMCPfBkOBwnC2LpBLZX9HebkaPuCKFr BoAAdsqvwVNODFeXGp7OAdReq1ydNSTe9rFh8epMtA8tkEGVVlQC66CTGU2KYc/m7PdS 64gd0yBMgZOZ5Cc84N4GtYvKOzGKsryvIqf521Oc4E79z4hsgLYiwlZbGjjTqV8HjQEV juEw==
X-Gm-Message-State: ALyK8tKIXdvkVRlO2uy0gGv6k/YIhdpcUmHD+Alp0mqVIP3OvcuxM/MVdm76CxNyJyIPpYfaZozTrfsPAgxOsg==
X-Received: by 10.159.36.205 with SMTP id 71mr8340178uar.121.1468530778647; Thu, 14 Jul 2016 14:12:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 14:12:57 -0700 (PDT)
In-Reply-To: 
References:   
From: Andy Bierman 
Date: Thu, 14 Jul 2016 14:12:57 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Content-Type: multipart/alternative; boundary=001a113e5dde674c4005379ef739
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 21:13:05 -0000

--001a113e5dde674c4005379ef739
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I do not like the server taking out locks on behalf of a client.
The client does not know this is happening and will not release the locks.

In general (in traditional NM) the server NEVER guesses about the
NMS intentions.  The server does what it is told.

The server should not create NP containers if default-operation=3Dnone.
If the client wanted that, it would pick 'merge'.


Andy


On Thu, Jul 14, 2016 at 1:30 PM, Sterne, Jason (Nokia - CA) <
jason.sterne@nokia.com> wrote:

> Thx Andy.  BTW -> This isn=E2=80=99t a purely academic question.  Nokia S=
R OS
> supports both writable-running and candidate.  And yes it is complex to
> manage.  The two datastores can=E2=80=99t be simply treated independently=
 and some
> locking/coherency mechanisms are needed between them.   But I think some =
of
> the same challenges exist for implementations that do =E2=80=9Cprivate=E2=
=80=9D candidates
> (in CLI or NETCONF).
>
>
>
> I agree with the deadlock (that was my last point).  That is one reason
> why it may make more sense to implicitly grab both locks on the server si=
de
> when the 1st one is asked for (i.e. reject the 2nd client=E2=80=99s lock =
request)
> instead of leaving this to the client side.
>
>
>
> But despite the challenges/disaster do you think it makes sense (and may
> almost be necessary) for the server to effectively grant both locks when
> either single one is taken ?
>
>
>
> Jason
>
>
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, July 14, 2016 15:14
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Netconf
> *Subject:* Re: [Netconf]  in a server that supports both
> writable-running and candidate
>
>
>
> Hi,
>
>
>
> IMO NETCONF locks are not well designed at all.
>
> For example, you are not even allowed to lock multiple datastores at once=
.
>
> You are forced to lock 1 at a time, and if 2 clients are doing this at th=
e
> same time,
>
> it can lead to a deadlock between them (Each 1 holding 1 lock waiting for
> the other)
>
>
>
> The shared candidate is sort of a disaster but if you want to use it
>
> then you will need to invent your own "git update".  The reason nobody
> implements
>
> :candidate and :writable-running together is because there is no way to
> synch
>
> the candidate if running has been changed underneath it.
>
>
>
> A concurrent write database is not "first writer wins, everybody else
> blows up".
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Jul 14, 2016 at 12:03 PM, Sterne, Jason (Nokia - CA) <
> jason.sterne@nokia.com> wrote:
>
> Hi all,
>
>
>
> I=E2=80=99m looking for opinions on how a client & server might interact =
for the
>  RPC when a server supports both writable-running and candidate DS.
>
>
>
> I suspect this is an unusual situation -> does anyone out there work with
> or have a server implementation that supports both ?
>
>
>
> The spirit of a  is to reserve exclusive access to alter the
> configuration of the device, and to prevent other clients (or management
> interfaces) from altering the config in the meantime.  I realize that in
> theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant) but I th=
ink that might be
> too simplistic for a system with both writable-running and candidate.
>
>
>
> In a server that supports both writable-running & candidate, it seems to
> make sense that a  of the running DS would also cause the server to
> implicitly lock the candidate (or at least reject a lock request of the
> candidate).  Otherwise (i.e. accepting a subsequent lock of the candidate=
)
> the client may assume since it has the candidate lock then it has the
> exclusive rights to the config and can happily edit & commit the config.
> It would be confusing to error on the commit (due to locking) after havin=
g
> accepted a lock.
>
>
>
> Similarly for the reverse situation -> if a client takes a candidate
>  then couldn=E2=80=99t it assume that nobody can subsequently block=
 their
> commit by taking a lock of the running DS ?
>
>
>
> It seems like the server should manage this interaction and avoid giving
> an =E2=80=9COK=E2=80=9D to clients taking the two locks on the two datast=
ores.
>
>
>
> On the other hand this could all be left up to the clients to deal with.
> Clients would have to see that a server has both a writeable-running and =
a
> candidate DS and take a lock of both.   But that would require all client=
s
> to have that behavior (instead of the server that supports the 2 DSes
> dealing with this).  It also has race conditions where the client takes 1
> lock but someone else gets the second lock.
>
>
>
> Opinions appreciated.
>
> Regards,
>
> Jason
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>

--001a113e5dde674c4005379ef739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I do not like the server taking out=
 locks on behalf of a client.
The client does not know this is ha=
ppening and will not release the locks.

In general=
 (in traditional NM) the server NEVER guesses about the
NMS inten=
tions.=C2=A0 The server does what it is told.

The =
server should not create NP containers if default-operation=3Dnone.
If the client wanted that, it would pick 'merge'.

=


Andy


On Thu, Jul 14, 2016 at 1:30 PM, St=
erne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote=
:











Thx Andy.=C2=A0 BTW ->=
 This isn=E2=80=99t a purely academic question.=C2=A0 Nokia SR OS supports =
both writable-running and candidate.=C2=A0 And yes it is complex to manage.=
=C2=A0 The two
 datastores can=E2=80=99t be simply treated independently and some locking/=
coherency mechanisms are needed between them.=C2=A0=C2=A0 But I think some =
of the same challenges exist for implementations that do =E2=80=9Cprivate=
=E2=80=9D candidates (in CLI or NETCONF).


=C2=A0


I agree with the deadlock=
 (that was my last point).=C2=A0 That is one reason why it may make more se=
nse to implicitly grab both locks on the server side when the
 1st one is asked for (i.e. reject the 2nd client=E2=
=80=99s lock request) instead of leaving this to the client side.=



=C2=A0


But despite the challenge=
s/disaster do you think it makes sense (and may almost be necessary) for th=
e server to effectively grant both locks when either single
 one is taken ?


=C2=A0


Jason


=C2=A0


=C2=A0




From: Netconf =
[mailto:netco=
nf-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: Thursday, July 14, 2016 15:14

To: Sterne, Jason (Nokia - CA)

Cc: Netconf

Subject: Re: [Netconf] <lock> in a server that supports both w=
ritable-running and candidate




=C2=A0




Hi,




=C2=A0






IMO NETCONF locks are not well designed at all.






For example, you are not even allowed to lock multip=
le datastores at once.






You are forced to lock 1 at a time, and if 2 clients=
 are doing this at the same time,






it can lead to a deadlock between them (Each 1 holdi=
ng 1 lock waiting for the other)






=C2=A0






The shared candidate is sort of a disaster but if yo=
u want to use it






then you will need to invent your own "git upda=
te".=C2=A0 The reason nobody implements






:candidate and :writable-running together is because=
 there is no way to synch






the candidate if running has been changed underneath=
 it.






=C2=A0






A concurrent write database is not "first write=
r wins, everybody else blows up".






=C2=A0






=C2=A0






Andy






=C2=A0






=C2=A0








=C2=A0




On Thu, Jul 14, 2016 at 12:03 PM, Sterne, Jason (Nok=
ia - CA) <ja=
son.sterne@nokia.com> wrote:






Hi all,






=C2=A0






I=E2=80=99m looking for opinions on how=
 a client & server might interact for the <lock> RPC when a serve=
r supports both writable-running and candidate DS.=C2=A0







=C2=A0






I suspect this is an unusual situation =
-> does anyone out there work with or have a server implementation that =
supports both ?






=C2=A0






The spirit of a <lock> is to rese=
rve exclusive access to alter the configuration of the device, and to preve=
nt other clients (or management interfaces) from altering the
 config in the meantime.=C2=A0 I realize that in theory the locks are =E2=
=80=9Cper-DS=E2=80=9D (i.e. independant) but I think that might be too simp=
listic for a system with both writable-running and candidate.=







=C2=A0






In a server that supports both writable=
-running & candidate, it seems to make sense that a <lock> of the=
 running DS would also cause the server to implicitly lock the candidate
 (or at least reject a lock request of the candidate).=C2=A0 Otherwise (i.e=
. accepting a subsequent lock of the candidate) the client may assume since=
 it has the candidate lock then it has the exclusive rights to the config a=
nd can happily edit & commit the config.=C2=A0
 It would be confusing to error on the commit (due to locking) after having=
 accepted a lock.






=C2=A0






Similarly for the reverse situation -&g=
t; if a client takes a candidate <lock> then couldn=E2=80=99t it assu=
me that nobody can subsequently block their commit by taking a lock of the
 running DS ?






=C2=A0






It seems like the server should manage =
this interaction and avoid giving an =E2=80=9COK=E2=80=9D to clients taking=
 the two locks on the two datastores.






=C2=A0






On the other hand this could all be lef=
t up to the clients to deal with.=C2=A0 Clients would have to see that a se=
rver has both a writeable-running and a candidate DS and take
 a lock of both.=C2=A0=C2=A0 But that would require all clients to have tha=
t behavior (instead of the server that supports the 2 DSes dealing with thi=
s).=C2=A0 It also has race conditions where the client takes 1 lock but som=
eone else gets the second lock.






=C2=A0






Opinions appreciated.






Regards,






Jason







=C2=A0








_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




=C2=A0












--001a113e5dde674c4005379ef739--


From nobody Thu Jul 14 14:15:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E9512D607 for ; Thu, 14 Jul 2016 14:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MuDGvwsz7dy8 for ; Thu, 14 Jul 2016 14:15:07 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98312D7B4 for ; Thu, 14 Jul 2016 14:15:06 -0700 (PDT)
Received: from dhcp-10-61-97-66.cisco.com (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 629FB1AE042E; Thu, 14 Jul 2016 23:15:04 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4797EB22-64A6-4F1B-B1EE-9E4083D4D3EE"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: 
Date: Thu, 14 Jul 2016 23:15:01 +0200
Message-Id: <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>       
To: Andy Bierman , "Sterne, Jason (Nokia - CA)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 21:15:09 -0000

--Apple-Mail=_4797EB22-64A6-4F1B-B1EE-9E4083D4D3EE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_029B149D-1F0F-4E16-9A1F-4BDAD770D88E"


--Apple-Mail=_029B149D-1F0F-4E16-9A1F-4BDAD770D88E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> I guess I don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=
=9D.  They are just structure and filtered out when empty.  I don=E2=80=99=
t really see this as the server =E2=80=9Cdeleting=E2=80=9D those =
containers.  It just suppresses them in  output.
>=20
> Please show me the RFC text that says the server can filter out NP =
containers.
> All config=3Dtrue data nodes are config.

In a very technical sense, I suppose the above statement is correct. An =
NP container is of course config true if it sits in the config true part =
of the tree. At the same time I agree with Janson's view that NP =
containers are just structure, so the question of their "existence" is =
moot.

Here's what RFC 6020, sec 7.5 says on the topic:

   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

So NP containers "exist only for organizing the hierarchy" while a P =
container "has an explicit meaning". I guess this implies NP containers =
having no meaning. Further down in 7.5.1, re P containers, it is noted =
that:

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.

Based on these fragments, I conclude that NP containers have zero bits =
of information. This means the existence/absence of an NP container =
cannot be known/stored/remembered even internally by a conforming =
system. The existence/absence of an NP container is a moot question. =
It's a bit like asking for the value of a void function. It's there, it =
has a name, but no value.

Implementations that receive a  or  request that =
contains an NP container will have to decide whether to include the NP =
container in the response or not. Since the existence of the NP =
container cannot be read from a database/etc (it has zero bits of =
information), the implementation will have to use some other way to =
determine whether to include it or not.

In order to make the life easier for implementors, the following MAY was =
introduced in sec 7.5.7:

   A NETCONF server that replies to a  or  request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.

So the NP container has to be included if it has children, or else the =
structural function of the container would be lost. If the NP container =
is empty, it may or may not be sent. Since an NP container has zero bits =
of information, this decision would not be based on whether it has been =
previously "created" or "deleted", but on implementation considerations. =
One possible approach is to always include it, another to actually check =
if there are any children, and only return it then.

Either way, NP containers alone have no meaning/information, they are =
only there for structure.

> A false must-stmt in an NP-container is still an error.

Certainly. Must statements on an NP container are always evaluated, even =
if the container hasn't been "created" or mentioned by a client, and =
even if it has no child elements.

> As Lada has pointed out many times, the text about
> NP containers not being part of the data model is just wrong.

I think the length of this discussion implies we should include this =
topic in the upcoming YANG FAQ.
> The server should not error in the cases Mahesh & Einar show -> the =
presence/existence of NP-containers shouldn=E2=80=99t really affect =
behavior (since they aren=E2=80=99t really config).
>=20
I agree with the above.
> But I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs =
to guard=E2=80=9D.  Do you agree that the server should not error in =
those cases below ?
>=20
> The YANG text says a server MAY delete an empty NP container.
> Using default-operation=3Dnone implies that the client is sure the =
nodes for operation=3Dnone
> actually exist.  Because of this YANG detail, the client cannot be =
sure so using
> default-operation=3Dnone may not work.

I disagree with this conclusion. Even using default-operation=3Dnone the =
transactions must be guaranteed to work by a conforming implementation. =
NP containers cannot be created/deleted in a deeper sense of the word =
since they have zero information content. They can only be referred to. =
Any must statements within the container must be evaluated regardless of =
the client ever mentioning the container.

/jan


--Apple-Mail=_029B149D-1F0F-4E16-9A1F-4BDAD770D88E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I guess I don=E2=80=99t really see =
NP-containers as =E2=80=9Cconfig=E2=80=9D.  They are just structure =
and filtered out when empty.  I don=E2=80=99t really see this as =
the server =E2=80=9Cdeleting=E2=80=9D
 those containers.  It just suppresses them in <get-config> =
output.   
Please show me the RFC text that says the server can filter =
out NP containers.
All config=3Dtrue data nodes are =
config.

In a very technical sense, I suppose the above =
statement is correct. An NP container is of course config true if it =
sits in the config true part of the tree. At the same time I agree with =
Janson's view that NP containers are just structure, so the question of =
their "existence" is moot. 

Here's what RFC 6020, sec 7.5 says on the =
topic:

   =
YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.


So NP containers =
"exist only for organizing the hierarchy" while a P container "has an =
explicit meaning". I guess this implies NP containers having no meaning. =
Further down in 7.5.1, re P containers, it is noted that:

   In the second style, the presence of =
the container itself is
   configuration data, representing a single bit of configuration data.

   The container acts as both a =
configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.


Based on =
these fragments, I conclude that NP containers have zero bits of =
information. This means the existence/absence of an NP container cannot =
be known/stored/remembered even internally by a conforming system. The =
existence/absence of an NP container is a moot question. It's a bit like =
asking for the value of a void function. It's there, it has a name, but =
no value.

Implementations that =
receive a <get> or <get-config> request that contains an NP =
container will have to decide whether to include the NP container in the =
response or not. Since the existence of the NP container cannot be read =
from a database/etc (it has zero bits of information), the =
implementation will have to use some other way to determine whether to =
include it or not.

In order to make =
the life easier for implementors, the following MAY was introduced in =
sec 7.5.7:

   A =
NETCONF server that replies to a <get> or <get-config> =
request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.

So the NP container has to be =
included if it has children, or else the structural function of the =
container would be lost. If the NP container is empty, it may or may not =
be sent. Since an NP container has zero bits of information, this =
decision would not be based on whether it has been previously "created" =
or "deleted", but on implementation considerations. One possible =
approach is to always include it, another to actually check if there are =
any children, and only return it then.

Either way, NP containers alone have no =
meaning/information, they are only there for structure.

A false must-stmt in an NP-container is still an =
error.

Certainly. Must statements on an NP container are =
always evaluated, even if the container hasn't been "created" or =
mentioned by a client, and even if it has no child elements.

As Lada has pointed out many times, the text about
NP containers not being part of the data model is just =
wrong.

I think the length of this discussion implies we =
should include this topic in the upcoming YANG FAQ.
The server should not error in the =
cases Mahesh & Einar show -> the presence/existence of =
NP-containers shouldn=E2=80=99t really affect behavior (since they =
aren=E2=80=99t
 really config). 
I agree with the above.
But I=E2=80=99m not positive what you =
mean by =E2=80=9Cmanager needs to guard=E2=80=9D.  Do you agree =
that the server should not error in those cases below =
?
The YANG text says =
a server MAY delete an empty NP container.
Using =
default-operation=3Dnone implies that the client is sure the nodes for =
operation=3Dnone
actually exist.  Because of =
this YANG detail, the client cannot be sure so using
default-operation=3Dnone may not =
work.

I=
 disagree with this conclusion. Even using default-operation=3Dnone the =
transactions must be guaranteed to work by a conforming implementation. =
NP containers cannot be created/deleted in a deeper sense of the word =
since they have zero information content. They can only be referred to. =
Any must statements within the container must be evaluated regardless of =
the client ever mentioning the container.

/jan

=

--Apple-Mail=_029B149D-1F0F-4E16-9A1F-4BDAD770D88E--

--Apple-Mail=_4797EB22-64A6-4F1B-B1EE-9E4083D4D3EE
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

iQEcBAEBCgAGBQJXiADVAAoJEBSCnbqufIisWhEH/0dWVB9LPeRJ/KtlmSV3pRLs
KShZHMZjE4arx9UPVHCSc1UoxeuCQl6n4VpKmApsr1pxt1HNLRKxo+6pWk8b8RV+
rPoS8SyMP0DqtTbiHqDXiux1pAreFE0ARTuoLXa+I7jCN20QmUlRWZLw8UcfoJ4+
3a8i2U/2cuE2GVL8VIK/Gx/0pDeNAHB7IxZK7xflKYjgC9Pq4zL2Uy2Eeu4xZFUE
G0jGRk+e6SXCeWKIQQCbdN5Jh7DboQMPFh7PZYbhy5rb/O9g547zNXan2bGEtunx
SIPTRiD2CtbH/TU1cp4YZYibGfwT1cCswywCOh1LDcxV4IOJlJ5022krCCgcqfY=
=vP3m
-----END PGP SIGNATURE-----

--Apple-Mail=_4797EB22-64A6-4F1B-B1EE-9E4083D4D3EE--


From nobody Thu Jul 14 14:41:37 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84DB12D0FD for ; Thu, 14 Jul 2016 14:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xw6WA0ZuBSPz for ; Thu, 14 Jul 2016 14:41:32 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4501312D53D for ; Thu, 14 Jul 2016 14:41:31 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 192FE69A51EC5; Thu, 14 Jul 2016 21:41:27 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6ELfTvo023665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2016 21:41:29 GMT
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6ELfTj0007981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jul 2016 21:41:29 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 17:41:29 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Andy Bierman 
Thread-Topic: [Netconf]  in a server that supports both writable-running and candidate
Thread-Index: AdHeAl/GLPvbP2zwTVylVCsJWBbO+AAIvxGAAAYCVGD///FAgIAAPB0w
Date: Thu, 14 Jul 2016 21:41:29 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCCA148US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 21:41:37 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCCA148US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGh4Lg0KDQpUaGUgYXBwcm9hY2ggSSB3YXMgcHJvcG9zaW5nIHdhcyBub3QgdGhhdCB0aGUgc2Vy
dmVyIHRha2VzIHRoZSBsb2NrIGV4cGxpY2l0bHkgYnV0IHRoYXQgaXQgdGFrZXMgaXQgaW1wbGlj
aXRseS4gIEl0IHdvdWxkIHJlamVjdCBhbiBhdHRlbXB0IGJ5IGEgY2xpZW50IHRvIHRha2UgdGhl
IG90aGVyIGxvY2ssIGJ1dCBub3QgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHJlbGVhc2UgYW55IDJu
ZCBsb2NrIChzaW5jZSBpdCBkaWRu4oCZdCB0YWtlIGl0KS4gICBUaGUgaW1wbGljaXQgbG9jayBv
biB0aGUgMm5kIERTIHdvdWxkIGJlIGF1dG9tYXRpY2FsbHkgcmVsZWFzZWQgKGp1c3QgbGlrZSBp
dCB3YXMgYXV0b21hdGljYWxseSB0YWtlbikuDQoNCkkgdGhpbmsgdGhhdCBpcyBtb3JlIGluIHRo
ZSBzcGlyaXQgb2Ygd2hhdCB0aGUgY2xpZW50IGlzIHRyeWluZyB0byB0ZWxsIHRoZSBzZXJ2ZXIu
ICBUaGUgY2xpZW50IChieSB0YWtpbmcgdGhlIDxjYW5kaWRhdGU+IGxvY2sgZm9yIGV4YW1wbGUp
IHdhbnRzIHRvIG1ha2Ugc3VyZSBpdCBoYXMgZXhjbHVzaXZlIGFjY2VzcyB0byBtb2RpZnkgdGhl
IGNvbmZpZy4gICBUaGUgYWx0ZXJuYXRpdmUgaXMgdGhhdCB0aGUgY2xpZW50IGdldHMgYSBsb2Nr
IGFuZCB0aGVuIGNvdWxkIHN1ZGRlbmx5IGJlIGJsb2NrZWQgKGJ5IGFub3RoZXIgbG9jaykgZnJv
bSB1cGRhdGluZyB0aGUgY29uZmlnLiAgVGhhdCBzZWVtcyB0byBkZWZlYXQgdGhlIHB1cnBvc2Uv
dXNlIG9mIHRoZSBsb2Nrcy4NCg0KUmVnYXJkcywNCkphc29uDQoNCkZyb206IEFuZHkgQmllcm1h
biBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0LCAy
MDE2IDE3OjEzDQpUbzogU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSkNCkNjOiBOZXRjb25mDQpT
dWJqZWN0OiBSZTogW05ldGNvbmZdIDxsb2NrPiBpbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIGJv
dGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlDQoNCkhpLA0KDQpJIGRvIG5vdCBsaWtl
IHRoZSBzZXJ2ZXIgdGFraW5nIG91dCBsb2NrcyBvbiBiZWhhbGYgb2YgYSBjbGllbnQuDQpUaGUg
Y2xpZW50IGRvZXMgbm90IGtub3cgdGhpcyBpcyBoYXBwZW5pbmcgYW5kIHdpbGwgbm90IHJlbGVh
c2UgdGhlIGxvY2tzLg0KDQpJbiBnZW5lcmFsIChpbiB0cmFkaXRpb25hbCBOTSkgdGhlIHNlcnZl
ciBORVZFUiBndWVzc2VzIGFib3V0IHRoZQ0KTk1TIGludGVudGlvbnMuICBUaGUgc2VydmVyIGRv
ZXMgd2hhdCBpdCBpcyB0b2xkLg0KDQpUaGUgc2VydmVyIHNob3VsZCBub3QgY3JlYXRlIE5QIGNv
bnRhaW5lcnMgaWYgZGVmYXVsdC1vcGVyYXRpb249bm9uZS4NCklmIHRoZSBjbGllbnQgd2FudGVk
IHRoYXQsIGl0IHdvdWxkIHBpY2sgJ21lcmdlJy4NCg0KDQpBbmR5DQoNCg0KT24gVGh1LCBKdWwg
MTQsIDIwMTYgYXQgMTozMCBQTSwgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSkgPGphc29uLnN0
ZXJuZUBub2tpYS5jb208bWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20+PiB3cm90ZToNClRo
eCBBbmR5LiAgQlRXIC0+IFRoaXMgaXNu4oCZdCBhIHB1cmVseSBhY2FkZW1pYyBxdWVzdGlvbi4g
IE5va2lhIFNSIE9TIHN1cHBvcnRzIGJvdGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRl
LiAgQW5kIHllcyBpdCBpcyBjb21wbGV4IHRvIG1hbmFnZS4gIFRoZSB0d28gZGF0YXN0b3JlcyBj
YW7igJl0IGJlIHNpbXBseSB0cmVhdGVkIGluZGVwZW5kZW50bHkgYW5kIHNvbWUgbG9ja2luZy9j
b2hlcmVuY3kgbWVjaGFuaXNtcyBhcmUgbmVlZGVkIGJldHdlZW4gdGhlbS4gICBCdXQgSSB0aGlu
ayBzb21lIG9mIHRoZSBzYW1lIGNoYWxsZW5nZXMgZXhpc3QgZm9yIGltcGxlbWVudGF0aW9ucyB0
aGF0IGRvIOKAnHByaXZhdGXigJ0gY2FuZGlkYXRlcyAoaW4gQ0xJIG9yIE5FVENPTkYpLg0KDQpJ
IGFncmVlIHdpdGggdGhlIGRlYWRsb2NrICh0aGF0IHdhcyBteSBsYXN0IHBvaW50KS4gIFRoYXQg
aXMgb25lIHJlYXNvbiB3aHkgaXQgbWF5IG1ha2UgbW9yZSBzZW5zZSB0byBpbXBsaWNpdGx5IGdy
YWIgYm90aCBsb2NrcyBvbiB0aGUgc2VydmVyIHNpZGUgd2hlbiB0aGUgMXN0IG9uZSBpcyBhc2tl
ZCBmb3IgKGkuZS4gcmVqZWN0IHRoZSAybmQgY2xpZW504oCZcyBsb2NrIHJlcXVlc3QpIGluc3Rl
YWQgb2YgbGVhdmluZyB0aGlzIHRvIHRoZSBjbGllbnQgc2lkZS4NCg0KQnV0IGRlc3BpdGUgdGhl
IGNoYWxsZW5nZXMvZGlzYXN0ZXIgZG8geW91IHRoaW5rIGl0IG1ha2VzIHNlbnNlIChhbmQgbWF5
IGFsbW9zdCBiZSBuZWNlc3NhcnkpIGZvciB0aGUgc2VydmVyIHRvIGVmZmVjdGl2ZWx5IGdyYW50
IGJvdGggbG9ja3Mgd2hlbiBlaXRoZXIgc2luZ2xlIG9uZSBpcyB0YWtlbiA/DQoNCkphc29uDQoN
Cg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86
bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2Vu
dDogVGh1cnNkYXksIEp1bHkgMTQsIDIwMTYgMTU6MTQNClRvOiBTdGVybmUsIEphc29uIChOb2tp
YSAtIENBKQ0KQ2M6IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gPGxvY2s+IGluIGEg
c2VydmVyIHRoYXQgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUN
Cg0KSGksDQoNCklNTyBORVRDT05GIGxvY2tzIGFyZSBub3Qgd2VsbCBkZXNpZ25lZCBhdCBhbGwu
DQpGb3IgZXhhbXBsZSwgeW91IGFyZSBub3QgZXZlbiBhbGxvd2VkIHRvIGxvY2sgbXVsdGlwbGUg
ZGF0YXN0b3JlcyBhdCBvbmNlLg0KWW91IGFyZSBmb3JjZWQgdG8gbG9jayAxIGF0IGEgdGltZSwg
YW5kIGlmIDIgY2xpZW50cyBhcmUgZG9pbmcgdGhpcyBhdCB0aGUgc2FtZSB0aW1lLA0KaXQgY2Fu
IGxlYWQgdG8gYSBkZWFkbG9jayBiZXR3ZWVuIHRoZW0gKEVhY2ggMSBob2xkaW5nIDEgbG9jayB3
YWl0aW5nIGZvciB0aGUgb3RoZXIpDQoNClRoZSBzaGFyZWQgY2FuZGlkYXRlIGlzIHNvcnQgb2Yg
YSBkaXNhc3RlciBidXQgaWYgeW91IHdhbnQgdG8gdXNlIGl0DQp0aGVuIHlvdSB3aWxsIG5lZWQg
dG8gaW52ZW50IHlvdXIgb3duICJnaXQgdXBkYXRlIi4gIFRoZSByZWFzb24gbm9ib2R5IGltcGxl
bWVudHMNCjpjYW5kaWRhdGUgYW5kIDp3cml0YWJsZS1ydW5uaW5nIHRvZ2V0aGVyIGlzIGJlY2F1
c2UgdGhlcmUgaXMgbm8gd2F5IHRvIHN5bmNoDQp0aGUgY2FuZGlkYXRlIGlmIHJ1bm5pbmcgaGFz
IGJlZW4gY2hhbmdlZCB1bmRlcm5lYXRoIGl0Lg0KDQpBIGNvbmN1cnJlbnQgd3JpdGUgZGF0YWJh
c2UgaXMgbm90ICJmaXJzdCB3cml0ZXIgd2lucywgZXZlcnlib2R5IGVsc2UgYmxvd3MgdXAiLg0K
DQoNCkFuZHkNCg0KDQoNCk9uIFRodSwgSnVsIDE0LCAyMDE2IGF0IDEyOjAzIFBNLCBTdGVybmUs
IEphc29uIChOb2tpYSAtIENBKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbTxtYWlsdG86amFzb24u
c3Rlcm5lQG5va2lhLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpJ4oCZbSBsb29raW5nIGZvciBv
cGluaW9ucyBvbiBob3cgYSBjbGllbnQgJiBzZXJ2ZXIgbWlnaHQgaW50ZXJhY3QgZm9yIHRoZSA8
bG9jaz4gUlBDIHdoZW4gYSBzZXJ2ZXIgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFu
ZCBjYW5kaWRhdGUgRFMuDQoNCkkgc3VzcGVjdCB0aGlzIGlzIGFuIHVudXN1YWwgc2l0dWF0aW9u
IC0+IGRvZXMgYW55b25lIG91dCB0aGVyZSB3b3JrIHdpdGggb3IgaGF2ZSBhIHNlcnZlciBpbXBs
ZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIGJvdGggPw0KDQpUaGUgc3Bpcml0IG9mIGEgPGxvY2s+
IGlzIHRvIHJlc2VydmUgZXhjbHVzaXZlIGFjY2VzcyB0byBhbHRlciB0aGUgY29uZmlndXJhdGlv
biBvZiB0aGUgZGV2aWNlLCBhbmQgdG8gcHJldmVudCBvdGhlciBjbGllbnRzIChvciBtYW5hZ2Vt
ZW50IGludGVyZmFjZXMpIGZyb20gYWx0ZXJpbmcgdGhlIGNvbmZpZyBpbiB0aGUgbWVhbnRpbWUu
ICBJIHJlYWxpemUgdGhhdCBpbiB0aGVvcnkgdGhlIGxvY2tzIGFyZSDigJxwZXItRFPigJ0gKGku
ZS4gaW5kZXBlbmRhbnQpIGJ1dCBJIHRoaW5rIHRoYXQgbWlnaHQgYmUgdG9vIHNpbXBsaXN0aWMg
Zm9yIGEgc3lzdGVtIHdpdGggYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUuDQoN
CkluIGEgc2VydmVyIHRoYXQgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5uaW5nICYgY2FuZGlk
YXRlLCBpdCBzZWVtcyB0byBtYWtlIHNlbnNlIHRoYXQgYSA8bG9jaz4gb2YgdGhlIHJ1bm5pbmcg
RFMgd291bGQgYWxzbyBjYXVzZSB0aGUgc2VydmVyIHRvIGltcGxpY2l0bHkgbG9jayB0aGUgY2Fu
ZGlkYXRlIChvciBhdCBsZWFzdCByZWplY3QgYSBsb2NrIHJlcXVlc3Qgb2YgdGhlIGNhbmRpZGF0
ZSkuICBPdGhlcndpc2UgKGkuZS4gYWNjZXB0aW5nIGEgc3Vic2VxdWVudCBsb2NrIG9mIHRoZSBj
YW5kaWRhdGUpIHRoZSBjbGllbnQgbWF5IGFzc3VtZSBzaW5jZSBpdCBoYXMgdGhlIGNhbmRpZGF0
ZSBsb2NrIHRoZW4gaXQgaGFzIHRoZSBleGNsdXNpdmUgcmlnaHRzIHRvIHRoZSBjb25maWcgYW5k
IGNhbiBoYXBwaWx5IGVkaXQgJiBjb21taXQgdGhlIGNvbmZpZy4gIEl0IHdvdWxkIGJlIGNvbmZ1
c2luZyB0byBlcnJvciBvbiB0aGUgY29tbWl0IChkdWUgdG8gbG9ja2luZykgYWZ0ZXIgaGF2aW5n
IGFjY2VwdGVkIGEgbG9jay4NCg0KU2ltaWxhcmx5IGZvciB0aGUgcmV2ZXJzZSBzaXR1YXRpb24g
LT4gaWYgYSBjbGllbnQgdGFrZXMgYSBjYW5kaWRhdGUgPGxvY2s+IHRoZW4gY291bGRu4oCZdCBp
dCBhc3N1bWUgdGhhdCBub2JvZHkgY2FuIHN1YnNlcXVlbnRseSBibG9jayB0aGVpciBjb21taXQg
YnkgdGFraW5nIGEgbG9jayBvZiB0aGUgcnVubmluZyBEUyA/DQoNCkl0IHNlZW1zIGxpa2UgdGhl
IHNlcnZlciBzaG91bGQgbWFuYWdlIHRoaXMgaW50ZXJhY3Rpb24gYW5kIGF2b2lkIGdpdmluZyBh
biDigJxPS+KAnSB0byBjbGllbnRzIHRha2luZyB0aGUgdHdvIGxvY2tzIG9uIHRoZSB0d28gZGF0
YXN0b3Jlcy4NCg0KT24gdGhlIG90aGVyIGhhbmQgdGhpcyBjb3VsZCBhbGwgYmUgbGVmdCB1cCB0
byB0aGUgY2xpZW50cyB0byBkZWFsIHdpdGguICBDbGllbnRzIHdvdWxkIGhhdmUgdG8gc2VlIHRo
YXQgYSBzZXJ2ZXIgaGFzIGJvdGggYSB3cml0ZWFibGUtcnVubmluZyBhbmQgYSBjYW5kaWRhdGUg
RFMgYW5kIHRha2UgYSBsb2NrIG9mIGJvdGguICAgQnV0IHRoYXQgd291bGQgcmVxdWlyZSBhbGwg
Y2xpZW50cyB0byBoYXZlIHRoYXQgYmVoYXZpb3IgKGluc3RlYWQgb2YgdGhlIHNlcnZlciB0aGF0
IHN1cHBvcnRzIHRoZSAyIERTZXMgZGVhbGluZyB3aXRoIHRoaXMpLiAgSXQgYWxzbyBoYXMgcmFj
ZSBjb25kaXRpb25zIHdoZXJlIHRoZSBjbGllbnQgdGFrZXMgMSBsb2NrIGJ1dCBzb21lb25lIGVs
c2UgZ2V0cyB0aGUgc2Vjb25kIGxvY2suDQoNCk9waW5pb25zIGFwcHJlY2lhdGVkLg0KUmVnYXJk
cywNCkphc29uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRj
b25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj
b25mDQoNCg0K

--_000_A125E53CE190A749957C19483DC79F9F5CCCA148US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv
QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl
LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoeC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlRoZSBhcHByb2FjaCBJIHdhcyBwcm9wb3Npbmcgd2FzIG5vdCB0aGF0IHRoZSBzZXJ2ZXIgdGFr
ZXMgdGhlIGxvY2sgZXhwbGljaXRseSBidXQgdGhhdCBpdCB0YWtlcyBpdCBpbXBsaWNpdGx5LiZu
YnNwOyBJdCB3b3VsZCByZWplY3QgYW4gYXR0ZW1wdCBieSBhIGNsaWVudCB0byB0YWtlDQogdGhl
IG90aGVyIGxvY2ssIGJ1dCBub3QgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHJlbGVhc2UgYW55IDI8
c3VwPm5kPC9zdXA+IGxvY2sgKHNpbmNlIGl0IGRpZG7igJl0IHRha2UgaXQpLiZuYnNwOyZuYnNw
OyBUaGUgaW1wbGljaXQgbG9jayBvbiB0aGUgMjxzdXA+bmQ8L3N1cD4gRFMgd291bGQgYmUgYXV0
b21hdGljYWxseSByZWxlYXNlZCAoanVzdCBsaWtlIGl0IHdhcyBhdXRvbWF0aWNhbGx5IHRha2Vu
KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCBpcyBtb3JlIGluIHRoZSBzcGlyaXQgb2Ygd2hhdCB0
aGUgY2xpZW50IGlzIHRyeWluZyB0byB0ZWxsIHRoZSBzZXJ2ZXIuJm5ic3A7IFRoZSBjbGllbnQg
KGJ5IHRha2luZyB0aGUgJmx0O2NhbmRpZGF0ZSZndDsgbG9jayBmb3IgZXhhbXBsZSkgd2FudHMg
dG8gbWFrZSBzdXJlDQogaXQgaGFzIGV4Y2x1c2l2ZSBhY2Nlc3MgdG8gbW9kaWZ5IHRoZSBjb25m
aWcuJm5ic3A7Jm5ic3A7IFRoZSBhbHRlcm5hdGl2ZSBpcyB0aGF0IHRoZSBjbGllbnQgZ2V0cyBh
IGxvY2sgYW5kIHRoZW4gY291bGQgc3VkZGVubHkgYmUgYmxvY2tlZCAoYnkgYW5vdGhlciBsb2Nr
KSBmcm9tIHVwZGF0aW5nIHRoZSBjb25maWcuJm5ic3A7IFRoYXQgc2VlbXMgdG8gZGVmZWF0IHRo
ZSBwdXJwb3NlL3VzZSBvZiB0aGUgbG9ja3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5KYXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5keSBCaWVybWFuIFttYWls
dG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5
IDE0LCAyMDE2IDE3OjEzPGJyPg0KPGI+VG86PC9iPiBTdGVybmUsIEphc29uIChOb2tpYSAtIENB
KTxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNv
bmZdICZsdDtsb2NrJmd0OyBpbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIGJvdGggd3JpdGFibGUt
cnVubmluZyBhbmQgY2FuZGlkYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgZG8gbm90IGxpa2UgdGhlIHNlcnZlciB0YWtpbmcgb3V0IGxvY2tzIG9uIGJlaGFsZiBv
ZiBhIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoZSBjbGllbnQgZG9lcyBub3Qga25vdyB0aGlzIGlzIGhhcHBlbmluZyBhbmQgd2ls
bCBub3QgcmVsZWFzZSB0aGUgbG9ja3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGdlbmVyYWwgKGluIHRyYWRpdGlvbmFsIE5NKSB0aGUg
c2VydmVyIE5FVkVSIGd1ZXNzZXMgYWJvdXQgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OTVMgaW50ZW50aW9ucy4mbmJzcDsgVGhlIHNlcnZl
ciBkb2VzIHdoYXQgaXQgaXMgdG9sZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlcnZlciBzaG91bGQgbm90IGNyZWF0ZSBOUCBjb250
YWluZXJzIGlmIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgY2xpZW50IHdhbnRlZCB0aGF0LCBp
dCB3b3VsZCBwaWNrICdtZXJnZScuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDE0LCAyMDE2IGF0IDE6MzAgUE0s
IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpICZsdDs8YSBocmVmPSJtYWlsdG86amFzb24uc3Rl
cm5lQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphc29uLnN0ZXJuZUBub2tpYS5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGh4IEFu
ZHkuJm5ic3A7IEJUVyAtJmd0OyBUaGlzIGlzbuKAmXQgYSBwdXJlbHkgYWNhZGVtaWMgcXVlc3Rp
b24uJm5ic3A7IE5va2lhIFNSIE9TIHN1cHBvcnRzIGJvdGggd3JpdGFibGUtcnVubmluZw0KIGFu
ZCBjYW5kaWRhdGUuJm5ic3A7IEFuZCB5ZXMgaXQgaXMgY29tcGxleCB0byBtYW5hZ2UuJm5ic3A7
IFRoZSB0d28gZGF0YXN0b3JlcyBjYW7igJl0IGJlIHNpbXBseSB0cmVhdGVkIGluZGVwZW5kZW50
bHkgYW5kIHNvbWUgbG9ja2luZy9jb2hlcmVuY3kgbWVjaGFuaXNtcyBhcmUgbmVlZGVkIGJldHdl
ZW4gdGhlbS4mbmJzcDsmbmJzcDsgQnV0IEkgdGhpbmsgc29tZSBvZiB0aGUgc2FtZSBjaGFsbGVu
Z2VzIGV4aXN0IGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyDigJxwcml2YXRl4oCdDQogY2Fu
ZGlkYXRlcyAoaW4gQ0xJIG9yIE5FVENPTkYpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB0
aGUgZGVhZGxvY2sgKHRoYXQgd2FzIG15IGxhc3QgcG9pbnQpLiZuYnNwOyBUaGF0IGlzIG9uZSBy
ZWFzb24gd2h5IGl0IG1heSBtYWtlIG1vcmUgc2Vuc2UNCiB0byBpbXBsaWNpdGx5IGdyYWIgYm90
aCBsb2NrcyBvbiB0aGUgc2VydmVyIHNpZGUgd2hlbiB0aGUgMTxzdXA+c3Q8L3N1cD4gb25lIGlz
IGFza2VkIGZvciAoaS5lLiByZWplY3QgdGhlIDI8c3VwPm5kPC9zdXA+IGNsaWVudOKAmXMgbG9j
ayByZXF1ZXN0KSBpbnN0ZWFkIG9mIGxlYXZpbmcgdGhpcyB0byB0aGUgY2xpZW50IHNpZGUuPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+QnV0IGRlc3BpdGUgdGhlIGNoYWxsZW5nZXMvZGlzYXN0ZXIgZG8geW91IHRo
aW5rIGl0IG1ha2VzIHNlbnNlIChhbmQgbWF5IGFsbW9zdCBiZSBuZWNlc3NhcnkpIGZvcg0KIHRo
ZSBzZXJ2ZXIgdG8gZWZmZWN0aXZlbHkgZ3JhbnQgYm90aCBsb2NrcyB3aGVuIGVpdGhlciBzaW5n
bGUgb25lIGlzIHRha2VuID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYXNvbjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5ldGNvbmYgW21haWx0bzo8YSBo
cmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0
Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVy
bWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDE0LCAyMDE2IDE1OjE0PGJyPg0K
PGI+VG86PC9iPiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKTxicj4NCjxiPkNjOjwvYj4gTmV0
Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdICZsdDtsb2NrJmd0OyBpbiBh
IHNlcnZlciB0aGF0IHN1cHBvcnRzIGJvdGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRl
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SU1PIE5FVENP
TkYgbG9ja3MgYXJlIG5vdCB3ZWxsIGRlc2lnbmVkIGF0IGFsbC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIGV4YW1wbGUsIHlvdSBhcmUg
bm90IGV2ZW4gYWxsb3dlZCB0byBsb2NrIG11bHRpcGxlIGRhdGFzdG9yZXMgYXQgb25jZS48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91IGFy
ZSBmb3JjZWQgdG8gbG9jayAxIGF0IGEgdGltZSwgYW5kIGlmIDIgY2xpZW50cyBhcmUgZG9pbmcg
dGhpcyBhdCB0aGUgc2FtZSB0aW1lLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5pdCBjYW4gbGVhZCB0byBhIGRlYWRsb2NrIGJldHdlZW4gdGhl
bSAoRWFjaCAxIGhvbGRpbmcgMSBsb2NrIHdhaXRpbmcgZm9yIHRoZSBvdGhlcik8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBzaGFy
ZWQgY2FuZGlkYXRlIGlzIHNvcnQgb2YgYSBkaXNhc3RlciBidXQgaWYgeW91IHdhbnQgdG8gdXNl
IGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PnRoZW4geW91IHdpbGwgbmVlZCB0byBpbnZlbnQgeW91ciBvd24gJnF1b3Q7Z2l0IHVwZGF0ZSZx
dW90Oy4mbmJzcDsgVGhlIHJlYXNvbiBub2JvZHkgaW1wbGVtZW50czxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj46Y2FuZGlkYXRlIGFuZCA6d3Jp
dGFibGUtcnVubmluZyB0b2dldGhlciBpcyBiZWNhdXNlIHRoZXJlIGlzIG5vIHdheSB0byBzeW5j
aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50
aGUgY2FuZGlkYXRlIGlmIHJ1bm5pbmcgaGFzIGJlZW4gY2hhbmdlZCB1bmRlcm5lYXRoIGl0Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
QSBjb25jdXJyZW50IHdyaXRlIGRhdGFiYXNlIGlzIG5vdCAmcXVvdDtmaXJzdCB3cml0ZXIgd2lu
cywgZXZlcnlib2R5IGVsc2UgYmxvd3MgdXAmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBU
aHUsIEp1bCAxNCwgMjAxNiBhdCAxMjowMyBQTSwgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSkg
Jmx0OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+amFzb24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+SGkgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SeKAmW0gbG9va2luZyBmb3Igb3Bpbmlv
bnMgb24gaG93IGEgY2xpZW50ICZhbXA7IHNlcnZlciBtaWdodCBpbnRlcmFjdCBmb3IgdGhlICZs
dDtsb2NrJmd0OyBSUEMgd2hlbiBhIHNlcnZlciBzdXBwb3J0cyBib3RoDQogd3JpdGFibGUtcnVu
bmluZyBhbmQgY2FuZGlkYXRlIERTLiZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgc3VzcGVjdCB0
aGlzIGlzIGFuIHVudXN1YWwgc2l0dWF0aW9uIC0mZ3Q7IGRvZXMgYW55b25lIG91dCB0aGVyZSB3
b3JrIHdpdGggb3IgaGF2ZSBhIHNlcnZlciBpbXBsZW1lbnRhdGlvbiB0aGF0DQogc3VwcG9ydHMg
Ym90aCA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgc3Bpcml0IG9mIGEgJmx0O2xvY2smZ3Q7IGlzIHRv
IHJlc2VydmUgZXhjbHVzaXZlIGFjY2VzcyB0byBhbHRlciB0aGUgY29uZmlndXJhdGlvbiBvZiB0
aGUgZGV2aWNlLCBhbmQgdG8gcHJldmVudA0KIG90aGVyIGNsaWVudHMgKG9yIG1hbmFnZW1lbnQg
aW50ZXJmYWNlcykgZnJvbSBhbHRlcmluZyB0aGUgY29uZmlnIGluIHRoZSBtZWFudGltZS4mbmJz
cDsgSSByZWFsaXplIHRoYXQgaW4gdGhlb3J5IHRoZSBsb2NrcyBhcmUg4oCccGVyLURT4oCdIChp
LmUuIGluZGVwZW5kYW50KSBidXQgSSB0aGluayB0aGF0IG1pZ2h0IGJlIHRvbyBzaW1wbGlzdGlj
IGZvciBhIHN5c3RlbSB3aXRoIGJvdGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+SW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoIHdyaXRhYmxlLXJ1
bm5pbmcgJmFtcDsgY2FuZGlkYXRlLCBpdCBzZWVtcyB0byBtYWtlIHNlbnNlIHRoYXQgYSAmbHQ7
bG9jayZndDsgb2YgdGhlIHJ1bm5pbmcNCiBEUyB3b3VsZCBhbHNvIGNhdXNlIHRoZSBzZXJ2ZXIg
dG8gaW1wbGljaXRseSBsb2NrIHRoZSBjYW5kaWRhdGUgKG9yIGF0IGxlYXN0IHJlamVjdCBhIGxv
Y2sgcmVxdWVzdCBvZiB0aGUgY2FuZGlkYXRlKS4mbmJzcDsgT3RoZXJ3aXNlIChpLmUuIGFjY2Vw
dGluZyBhIHN1YnNlcXVlbnQgbG9jayBvZiB0aGUgY2FuZGlkYXRlKSB0aGUgY2xpZW50IG1heSBh
c3N1bWUgc2luY2UgaXQgaGFzIHRoZSBjYW5kaWRhdGUgbG9jayB0aGVuIGl0IGhhcyB0aGUgZXhj
bHVzaXZlDQogcmlnaHRzIHRvIHRoZSBjb25maWcgYW5kIGNhbiBoYXBwaWx5IGVkaXQgJmFtcDsg
Y29tbWl0IHRoZSBjb25maWcuJm5ic3A7IEl0IHdvdWxkIGJlIGNvbmZ1c2luZyB0byBlcnJvciBv
biB0aGUgY29tbWl0IChkdWUgdG8gbG9ja2luZykgYWZ0ZXIgaGF2aW5nIGFjY2VwdGVkIGEgbG9j
ay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPlNpbWlsYXJseSBmb3IgdGhlIHJldmVyc2Ugc2l0dWF0aW9uIC0m
Z3Q7IGlmIGEgY2xpZW50IHRha2VzIGEgY2FuZGlkYXRlICZsdDtsb2NrJmd0OyB0aGVuIGNvdWxk
buKAmXQgaXQgYXNzdW1lIHRoYXQgbm9ib2R5DQogY2FuIHN1YnNlcXVlbnRseSBibG9jayB0aGVp
ciBjb21taXQgYnkgdGFraW5nIGEgbG9jayBvZiB0aGUgcnVubmluZyBEUyA/PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5JdCBzZWVtcyBsaWtlIHRoZSBzZXJ2ZXIgc2hvdWxkIG1hbmFnZSB0aGlzIGludGVyYWN0
aW9uIGFuZCBhdm9pZCBnaXZpbmcgYW4g4oCcT0vigJ0gdG8gY2xpZW50cyB0YWtpbmcgdGhlIHR3
byBsb2Nrcw0KIG9uIHRoZSB0d28gZGF0YXN0b3Jlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIHRoZSBv
dGhlciBoYW5kIHRoaXMgY291bGQgYWxsIGJlIGxlZnQgdXAgdG8gdGhlIGNsaWVudHMgdG8gZGVh
bCB3aXRoLiZuYnNwOyBDbGllbnRzIHdvdWxkIGhhdmUgdG8gc2VlIHRoYXQgYSBzZXJ2ZXINCiBo
YXMgYm90aCBhIHdyaXRlYWJsZS1ydW5uaW5nIGFuZCBhIGNhbmRpZGF0ZSBEUyBhbmQgdGFrZSBh
IGxvY2sgb2YgYm90aC4mbmJzcDsmbmJzcDsgQnV0IHRoYXQgd291bGQgcmVxdWlyZSBhbGwgY2xp
ZW50cyB0byBoYXZlIHRoYXQgYmVoYXZpb3IgKGluc3RlYWQgb2YgdGhlIHNlcnZlciB0aGF0IHN1
cHBvcnRzIHRoZSAyIERTZXMgZGVhbGluZyB3aXRoIHRoaXMpLiZuYnNwOyBJdCBhbHNvIGhhcyBy
YWNlIGNvbmRpdGlvbnMgd2hlcmUgdGhlIGNsaWVudCB0YWtlcyAxIGxvY2sNCiBidXQgc29tZW9u
ZSBlbHNlIGdldHMgdGhlIHNlY29uZCBsb2NrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T3BpbmlvbnMgYXBw
cmVjaWF0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHMsPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphc29uDQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TmV0Y29uZkBpZXRmLm9yZzwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCCA148US70TWXCHMBA11z_--


From nobody Thu Jul 14 14:48:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04D112D87F for ; Thu, 14 Jul 2016 14:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-KNhMNu3ig6 for ; Thu, 14 Jul 2016 14:48:33 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D035812D87B for ; Thu, 14 Jul 2016 14:48:32 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id w127so71986633vkh.2 for ; Thu, 14 Jul 2016 14:48:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DWztEV5ab+X7j35drWUII79e1J9fz7GIelTixLRBAAY=; b=u8zIXaDf9y4JAs4rEgf42kYOG3HCB76SIGeB1iAQC1QimsMWGzIwcHNd+LOkHbHn63 zJx8hv3U/d33K0WMZMWrI/71LR/TpIgelpOm5jZWKcIdEnQeI9qhFgN4bUj3vd88U4HF 390ToBE2XXw4uKWO78bUCpJMkQpWLRqqrbx+FsN4q39tV4gUp3tLTNHUHeXq5YvOQtm9 6/r5OUwvB0v2nNqr5Bgg8Vvr+oe0nBy+fnOJZxRsubPIV7jygyf114liaLlugetjUBmP yEdEWyyn6miUQb2vXvjv1JtvQTzozeVC9ETbe1oRL4wzdercffYmHNYuLAVd//jXrMvi voTA==
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; bh=DWztEV5ab+X7j35drWUII79e1J9fz7GIelTixLRBAAY=; b=UzzxHyD2rNsycqUV2ExTCHxDPgwqLGAdIepBeevrIwMHPtKio2dMS29QpEZB+GU1uB SRUntEy7VvLD9ZjSD+3HgUedJ9pyyruIoB6X+rjDrZ/JHcdxTAP3uOYNGSxebDNM68oA CW9zPDIxc5Q4UGvI5TUqlWpbAe8bVd6mN+73KtYus1goKwwpQuTeHhX7GOhLPCrtC02U Ngl8MkMMgKGpwJm1RFor3gs7mcRRB7z8JoP29G3ze4Zr4cYlB5yi7MlmXmy1xF4zmuYO Rob8/ipG7xEhxgSLkwcOwg72YDU7QMdR/cCV+mGcEEW6pb9cCDcobKDqalB3IdRomQXR FYxA==
X-Gm-Message-State: ALyK8tIi/1sbSmydmsdcyYK/fr1hIyGCdYW/t2W1NvYdK5DTbkef4gPs9OA5n/bvZ21+qQkQy07z728CEGJOXQ==
X-Received: by 10.159.35.112 with SMTP id 103mr8304398uae.55.1468532911893; Thu, 14 Jul 2016 14:48:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 14:48:31 -0700 (PDT)
In-Reply-To: <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>
From: Andy Bierman 
Date: Thu, 14 Jul 2016 14:48:31 -0700
Message-ID: 
To: Jan Lindblad 
Content-Type: multipart/alternative; boundary=001a113ab81a8e258805379f7675
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 21:48:37 -0000

--001a113ab81a8e258805379f7675
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 14, 2016 at 2:15 PM, Jan Lindblad  wrote:

> I guess I don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=
=9D.  They are just
>> structure and filtered out when empty.  I don=E2=80=99t really see this =
as the
>> server =E2=80=9Cdeleting=E2=80=9D those containers.  It just suppresses =
them in
>>  output.
>>
> Please show me the RFC text that says the server can filter out NP
> containers.
> All config=3Dtrue data nodes are config.
>
>
> In a very technical sense, I suppose the above statement is correct. An N=
P
> container is of course config true if it sits in the config true part of
> the tree. At the same time I agree with Janson's view that NP containers
> are just structure, so the question of their "existence" is moot.
>
> Here's what RFC 6020, sec 7.5 says on the topic:
>
>    YANG supports two styles of containers, those that exist only for
>    organizing the hierarchy of data nodes, and those whose presence in
>    the configuration has an explicit meaning.
>
>
> So NP containers "exist only for organizing the hierarchy" while a P
> container "has an explicit meaning". I guess this implies NP containers
> having no meaning. Further down in 7.5.1, re P containers, it is noted th=
at:
>
>    In the second style, the presence of the container itself is
>    configuration data, representing a single bit of configuration data.
>
>    The container acts as both a configuration knob and a means of
>    organizing related configuration.  These containers are explicitly
>    created and deleted.
>
>
> Based on these fragments, I conclude that NP containers have zero bits of
> information. This means the existence/absence of an NP container cannot b=
e
> known/stored/remembered even internally by a conforming system. The
> existence/absence of an NP container is a moot question. It's a bit like
> asking for the value of a void function. It's there, it has a name, but n=
o
> value.
>
> Implementations that receive a  or  request that contain=
s
> an NP container will have to decide whether to include the NP container i=
n
> the response or not. Since the existence of the NP container cannot be re=
ad
> from a database/etc (it has zero bits of information), the implementation
> will have to use some other way to determine whether to include it or not=
.
>
> In order to make the life easier for implementors, the following MAY was
> introduced in sec 7.5.7:
>
>    A NETCONF server that replies to a  or  request MAY
>    choose not to send a container element if the container node does not
>    have the "presence" statement and no child nodes exist.
>
>
> So the NP container has to be included if it has children, or else the
> structural function of the container would be lost. If the NP container i=
s
> empty, it may or may not be sent. Since an NP container has zero bits of
> information, this decision would not be based on whether it has been
> previously "created" or "deleted", but on implementation considerations.
> One possible approach is to always include it, another to actually check =
if
> there are any children, and only return it then.
>
> Either way, NP containers alone have no meaning/information, they are onl=
y
> there for structure.
>
> A false must-stmt in an NP-container is still an error.
>
>
> Certainly. Must statements on an NP container are always evaluated, even
> if the container hasn't been "created" or mentioned by a client, and even
> if it has no child elements.
>
> As Lada has pointed out many times, the text about
> NP containers not being part of the data model is just wrong.
>
>
> I think the length of this discussion implies we should include this topi=
c
> in the upcoming YANG FAQ.
>
> The server should not error in the cases Mahesh & Einar show -> the
>> presence/existence of NP-containers shouldn=E2=80=99t really affect beha=
vior (since
>> they aren=E2=80=99t really config).
>>
> I agree with the above.
>
> But I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs to g=
uard=E2=80=9D.  Do you
>> agree that the server should not error in those cases below ?
>>
> The YANG text says a server MAY delete an empty NP container.
> Using default-operation=3Dnone implies that the client is sure the nodes =
for
> operation=3Dnone
> actually exist.  Because of this YANG detail, the client cannot be sure s=
o
> using
> default-operation=3Dnone may not work.
>
>
> I disagree with this conclusion. Even using default-operation=3Dnone the
> transactions must be guaranteed to work by a conforming implementation. N=
P
> containers cannot be created/deleted in a deeper sense of the word since
> they have zero information content. They can only be referred to. Any mus=
t
> statements within the container must be evaluated regardless of the clien=
t
> ever mentioning the container.
>
>

I do not agree that default-operation=3Dnone does not apply to NP container=
s.

This is why it was such a bad decision to spread little pieces of NETCONF
all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
and it does not say anything about special treatment for NP containers.

   none:  The target datastore is unaffected by the configuration
            in the  parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the 
            parameter contains data for which there is not a
            corresponding level in the target datastore, an 
            is returned with an  value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.




> /jan
>
>
Andy

--001a113ab81a8e258805379f7675
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 14, 2016 at 2:15 PM, Jan Lindblad <janl@tail-f.com> wrote:
<=
blockquote type=3D"cite">
I guess I don=E2=80=99t r=
eally see NP-containers as =E2=80=9Cconfig=E2=80=9D.=C2=A0 They are just st=
ructure and filtered out when empty.=C2=A0 I don=E2=80=99t really see this =
as the server =E2=80=9Cdeleting=E2=80=9D
 those containers.=C2=A0 It just suppresses them in <get-config> outp=
ut. =C2=A0=C2=A0
Ple=
ase show me the RFC text that says the server can filter out NP containers.=

All config=3Dtrue data nodes are config.
=


In a very technical sense, I suppose the a=
bove statement is correct. An NP container is of course config true if it s=
its in the config true part of the tree. At the same time I agree with Jans=
on's view that NP containers are just structure, so the question of the=
ir "existence" is moot.=C2=A0

Here's=
 what RFC 6020, sec 7.5 says on the topic:

   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.


So NP containers "exist only for organ=
izing the hierarchy" while a P container "has an explicit meaning=
". I guess this implies NP containers having no meaning. Further down =
in 7.5.1, re P containers, it is noted that:

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.

   The container acts as both a configuration knob a=
nd a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.


Based on these fragments, I conclude =
that NP containers have zero bits of information. This means the existence/=
absence of an NP container cannot be known/stored/remembered even internall=
y by a conforming system. The existence/absence of an NP container is a moo=
t question. It's a bit like asking for the value of a void function. It=
's there, it has a name, but no value.

Impleme=
ntations that receive a <get> or <get-config> request that cont=
ains an NP container will have to decide whether to include the NP containe=
r in the response or not. Since the existence of the NP container cannot be=
 read from a database/etc (it has zero bits of information), the implementa=
tion will have to use some other way to determine whether to include it or =
not.

In order to make the life easier for implemen=
tors, the following MAY was introduced in sec 7.5.7:

   A NETCONF server that replies to a <get> or <get=
-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.
<=
div>
So the NP container has to be included if it has c=
hildren, or else the structural function of the container would be lost. If=
 the NP container is empty, it may or may not be sent. Since an NP containe=
r has zero bits of information, this decision would not be based on whether=
 it has been previously "created" or "deleted", but on =
implementation considerations. One possible approach is to always include i=
t, another to actually check if there are any children, and only return it =
then.

Either way, NP containers alone have no mean=
ing/information, they are only there for structure.

A false must-stmt in an NP-container is still an error.
<=
/div>

Certainly. Must statement=
s on an NP container are always evaluated, even if the container hasn't=
 been "created" or mentioned by a client, and even if it has no c=
hild elements.

As Lada has pointed out =
many times, the text about
NP containers not being part of the da=
ta model is just wrong.

=

I think the length of this discussion implies we should include this t=
opic in the upcoming YANG FAQ.
=

The server should not error in the cases Mahesh & Einar sho=
w -> the presence/existence of NP-containers shouldn=E2=80=99t really af=
fect behavior (since they aren=E2=80=99t
 really config).=C2=A0
I agree with the above.
But I=E2=80=99m not positive what you mean =
by =E2=80=9Cmanager needs to guard=E2=80=9D.=C2=A0 Do you agree that the se=
rver should not error in those cases below ?
The YANG text says a server MAY delete an empty NP container.
Using default-operation=3Dnone implies that the client is sure the n=
odes for operation=3Dnone
actually exist.=C2=A0 Because of this Y=
ANG detail, the client cannot be sure so using
default-operation=
=3Dnone may not work.

I disagree with this conclusion. Even using default-operation=3Dnone the=
 transactions must be guaranteed to work by a conforming implementation. NP=
 containers cannot be created/deleted in a deeper sense of the word since t=
hey have zero information content. They can only be referred to. Any must s=
tatements within the container must be evaluated regardless of the client e=
ver mentioning the container.


=

I do not agree that default-operation=3Dnone does not apply =
to NP containers.

This is why it was such a bad de=
cision to spread little pieces of NETCONF
all over the YANG RFC. =
RFC 6241 defines the 'default-operation' leaf
and it does=
 not say anything about special treatment for NP containers.

=

   none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to =
request
            a different operation.  If the configuration in the <config&=
gt;
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error&g=
t;
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete"=
; to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


=C2=A0
/jan


Andy



--001a113ab81a8e258805379f7675--


From nobody Thu Jul 14 14:53:42 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7612D8A5 for ; Thu, 14 Jul 2016 14:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI8xIB-UjDZV for ; Thu, 14 Jul 2016 14:53:37 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEFF12D8B4 for ; Thu, 14 Jul 2016 14:53:37 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id p64so197312pfb.1 for ; Thu, 14 Jul 2016 14:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Qn+DejImb6ni0MLZOx7JYMOjphOCUfIn+SkRfAzFC+M=; b=Qo1KIqqFpOl/RIJMxJTEDQINd6UrC7RQ6iCRqA4hERPRaRjyrKWAPvI2gxvC1FVhIo RRYWn1l7PlVASioKUfMQqKs+KjNvmNAa5cFxPIc0oJjKZ4WEndjmbXRQX8DhA1TwpXvr KUBSPl3jKesOk4NQVgu6cwwTs6RpBIFSj4K8kCFlFR3YCVC329nNwxAg/WIAKP4Td/ZY m2UU+nZAcyziLPstVQ+EpnfsMDE2dLOuziqR3OWDlVt3p374JYaPydM5b4oGTb8APFSs 764S1JC9ZMjl0o5WIvLCi8k4qgArup9ZwXoPkDcUmow8uGcZVtbsdYEvCBmAD7aQm/D/ wJfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Qn+DejImb6ni0MLZOx7JYMOjphOCUfIn+SkRfAzFC+M=; b=AjTMhvZ0SlU88tgsaVqnL3mEkT9UwMPMtHk/Dg74RxmdwTz6NvIxCvq7GQt24cYDHO 0JH+13y4GOAHV78fY/xI6kTlDqeGQqIdJpXz9Fr1nJ4VchJFdX6LX54x9RTRH24dSVax yZdR3k1r2bRQ6dL9ukA4oOFSt6P6JRgGgA5F1tAgUF2tpnrBfPTRAK8yIRhhY5P6IKHH OymO7hY7/6npDYTfyVatsVh+2oL0LIPPYk5e1BaEeaVL7ItRb7RXb/fpaC+DOYoXNsyg c5HDNG3ZrUZ+t8Fpw1y4JINZ1mDzN6LX5SpkoolJyr0rc0oExaOn13kt5YraohX5YlqX XcHQ==
X-Gm-Message-State: ALyK8tJSKlmMI/MW3ZIW7JmJqKU/Fb2HQ3jbEVPkaZaT5eQr4aEih/NEGI1b5YbvL0tC6Q==
X-Received: by 10.98.216.199 with SMTP id e190mr16176392pfg.123.1468533217129;  Thu, 14 Jul 2016 14:53:37 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1003::6a6? ([2001:420:c0c8:1003::6a6]) by smtp.gmail.com with ESMTPSA id 9sm3815935pfo.74.2016.07.14.14.53.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 14:53:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_53ECCC75-122D-4C1F-9149-CBA738455BF1"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Thu, 14 Jul 2016 14:53:27 -0700
Message-Id: <40DE01C9-4528-493A-A0C6-08AA4648D900@gmail.com>
References:  <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com> 
To: "Sterne, Jason (Nokia - CA)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 21:53:40 -0000

--Apple-Mail=_53ECCC75-122D-4C1F-9149-CBA738455BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Jason,

> On Jul 14, 2016, at 1:34 PM, Sterne, Jason (Nokia - CA) =
 wrote:
>=20
> Hi Mahesh,
> =20
> I=E2=80=99m not sure I understand your first statement.  Can you =
explain further ?  Are you saying that on a system that supports both =
writable-running and candidate you think clients may just take the lock =
on the candidate, do their updated, commit and then release the lock ?   =
I think that is reasonable/possible.

What I was stating was a statement of fact. Here is a typical =
transaction that I see. Notice, no effort to lock the running =
configuration.


  
    
      
    
  



  



  
    
      
    
    test-then-set
    rollback-on-error
    
      =E2=80=A6 config stuff
    
  



  



  
    
  



  



  



  



  
    
      
    
  



  



  



> =20
> As for preventing other mgmnt. interfaces from interfering -> I think =
RFC6241 is reasonably clear that should be prevented:
> =20
> Additionally, the system
>       will ensure that these locked configuration resources will not =
be
>       modified by other non-NETCONF management operations such as SNMP
>       and CLI.
> =20
> I agree with the general workflow but the question is whether the =
client should explicitly get both locks, or whether the server side =
should implicitly take both locks (i.e. prevent separate =
modifications/lock of the other DS).  It isn=E2=80=99t obvious but I =
lean towards the server side handling this situation (especially since =
the combination of writeable-running and candidate support is somewhat =
rare).
> =20
> Jason
> =20
> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20
> Sent: Thursday, July 14, 2016 16:01
> To: Sterne, Jason (Nokia - CA)
> Cc: Netconf
> Subject: Re: [Netconf]  in a server that supports both =
writable-running and candidate
> =20
> I see clients acquiring lock on the candidate config but not on =
running. You are right that it does not prevent, say RESTCONF or even =
CLI from updating the running-config directly.
> =20
> A workflow for what should be happening is:
> =20
> - acquire lock on candidate and running (can create deadlock as Andy =
mentions)
> - edit the candidate config
> - validate candidate config
> - commit candidate to running
> - release lock on candidate and running
> =20
> =20
> On Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia - CA) =
> wrote:
> =20
> Hi all,
> =20
> I=E2=80=99m looking for opinions on how a client & server might =
interact for the  RPC when a server supports both writable-running =
and candidate DS. =20
> =20
> I suspect this is an unusual situation -> does anyone out there work =
with or have a server implementation that supports both ?
> =20
> The spirit of a  is to reserve exclusive access to alter the =
configuration of the device, and to prevent other clients (or management =
interfaces) from altering the config in the meantime.  I realize that in =
theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant) but I =
think that might be too simplistic for a system with both =
writable-running and candidate.
> =20
> In a server that supports both writable-running & candidate, it seems =
to make sense that a  of the running DS would also cause the =
server to implicitly lock the candidate (or at least reject a lock =
request of the candidate).  Otherwise (i.e. accepting a subsequent lock =
of the candidate) the client may assume since it has the candidate lock =
then it has the exclusive rights to the config and can happily edit & =
commit the config.  It would be confusing to error on the commit (due to =
locking) after having accepted a lock.
> =20
> Similarly for the reverse situation -> if a client takes a candidate =
 then couldn=E2=80=99t it assume that nobody can subsequently =
block their commit by taking a lock of the running DS ?
> =20
> It seems like the server should manage this interaction and avoid =
giving an =E2=80=9COK=E2=80=9D to clients taking the two locks on the =
two datastores.
> =20
> On the other hand this could all be left up to the clients to deal =
with.  Clients would have to see that a server has both a =
writeable-running and a candidate DS and take a lock of both.   But that =
would require all clients to have that behavior (instead of the server =
that supports the 2 DSes dealing with this).  It also has race =
conditions where the client takes 1 lock but someone else gets the =
second lock.
> =20
> Opinions appreciated.
> Regards,
> Jason=20
> =20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

> =20
> Mahesh Jethanandani
> mjethanandani@gmail.com 
Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_53ECCC75-122D-4C1F-9149-CBA738455BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Jason,

On Jul 14, 2016, at 1:34 PM, =
Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:

Hi Mahesh,
 
I=E2=80=99m not sure I =
understand your first statement.  Can you explain further ?  =
Are you saying that on a system that supports both writable-running and =
candidate you think clients may just take the lock on the candidate, do =
their updated, commit and then release the lock ?   I think =
that is =
reasonable/possible.

What I was stating was a statement of fact. Here is a =
typical transaction that I see. Notice, no effort to lock the running =
configuration.

<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
  =
   message-id=3D"2">
  =
<lock>
    <target>
  =
    <candidate/>
    =
</target>
  =
</lock>
</rpc>

<rpc-reply message-id=3D=E2=80=9C2"
&nb=
sp;         =
 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
&nbs=
p; <ok/>
</rpc-reply>

<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
  =
   message-id=3D"3">
  <edit-config =
xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  =
  <target>
      =
<candidate/>
    </target>
    =
<test-option>test-then-set</test-option>
    =
<error-option>rollback-on-error</error-option>
    <config>
  =
    =E2=80=A6 config stuff
    =
</config>
  =
</edit-config>
</rpc>

<rpc-reply =
message-id=3D"3"
          =
 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id=3D"4">
  <commit>
    =
<confirmed/>
  =
</commit>
</rpc>

<rpc-reply message-id=3D"4"
  =
        =
 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id=3D"5">
  <commit/>
</rpc>

<rpc-reply message-id=3D"5"
          =
 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id=3D"6">
  <unlock>
    =
<target>
      =
<candidate/>
    =
</target>
  </unlock>
</rpc>

<rpc-reply message-id=3D"6"
  =
        =
 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

<rpc =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id=3D"7">
  <close-session/>
</rpc>


 
As for preventing other =
mgmnt. interfaces from interfering -> I think RFC6241 is reasonably =
clear that should be prevented:
 
Additionally, the =
system
      will ensure that these locked =
configuration resources will not be
      modified by other non-NETCONF =
management operations such as SNMP
      and CLI.
 
I agree with the =
general workflow but the question is whether the client should =
explicitly get both locks, or whether the server side should implicitly =
take both locks (i.e. prevent separate modifications/lock of the other =
DS).  It isn=E2=80=99t obvious but I lean towards the server side =
handling this situation (especially since the combination of =
writeable-running and candidate support is somewhat rare).
 
Jason
 
From: Mahesh =
Jethanandani [mailto:mjethanandani@gmail.com] 
Sent: Thursday, July 14, 2016 =
16:01
To: Sterne, Jason (Nokia - =
CA)
Cc: Netconf
Subject: Re: [Netconf] <lock> =
in a server that supports both writable-running and candidate
 
I see clients acquiring lock on the =
candidate config but not on running. You are right that it does not =
prevent, say RESTCONF or even CLI from updating the running-config =
directly.
 
A workflow for what should be happening is:
 
- acquire lock on candidate and running =
(can create deadlock as Andy mentions)
- edit the candidate config
- validate candidate config
- commit candidate to running
- release lock on candidate and running
 
 
On =
Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> =
wrote:
 
Hi=
 all,
 
I=E2=80=99m looking for opinions on how a client =
& server might interact for the <lock> RPC when a server =
supports both writable-running and candidate DS.  
 
I suspect this is an unusual situation -> =
does anyone out there work with or have a server implementation that =
supports both ?
 
The spirit of a <lock> is to reserve exclusive access =
to alter the configuration of the device, and to prevent other clients =
(or management interfaces) from altering the config in the =
meantime.  I realize that in theory the locks are =E2=80=9Cper-DS=E2=80=
=9D (i.e. independant) but I think that might be too simplistic for a =
system with both writable-running and candidate.
 
In a server that supports both writable-running =
& candidate, it seems to make sense that a <lock> of the =
running DS would also cause the server to implicitly lock the candidate =
(or at least reject a lock request of the candidate).  Otherwise =
(i.e. accepting a subsequent lock of the candidate) the client may =
assume since it has the candidate lock then it has the exclusive rights =
to the config and can happily edit & commit the config.  It =
would be confusing to error on the commit (due to locking) after having =
accepted a lock.
 
Similarly for the reverse situation -> if a client takes a =
candidate <lock> then couldn=E2=80=99t it assume that nobody can =
subsequently block their commit by taking a lock of the running DS ?
 
It seems like the server should manage this =
interaction and avoid giving an =E2=80=9COK=E2=80=9D to clients taking =
the two locks on the two datastores.
 
On the other hand this could all be left up to =
the clients to deal with.  Clients would have to see that a server =
has both a writeable-running and a candidate DS and take a lock of =
both.   But that would require all clients to have that =
behavior (instead of the server that supports the 2 DSes dealing with =
this).  It also has race conditions where the client takes 1 lock =
but someone else gets the second lock.
 
Opinions appreciated.
Regards,
Jason 
 
_______________________________________________Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
 
Mahesh Jethanandani
mjethanandani@gmail.com



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_53ECCC75-122D-4C1F-9149-CBA738455BF1--


From nobody Thu Jul 14 14:57:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7DF12D848 for ; Thu, 14 Jul 2016 14:57:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 knWiiT74SeCY for ; Thu, 14 Jul 2016 14:57:07 -0700 (PDT)
Received: from p3plsmtpa12-08.prod.phx3.secureserver.net (p3plsmtpa12-08.prod.phx3.secureserver.net [68.178.252.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C364D12D696 for ; Thu, 14 Jul 2016 14:57:07 -0700 (PDT)
Received: from [192.168.10.101] ([24.13.90.46]) by p3plsmtpa12-08.prod.phx3.secureserver.net with  id Jlww1t003100Es801lwwGv; Thu, 14 Jul 2016 14:57:07 -0700
To: Jan Lindblad , Andy Bierman , "Sterne, Jason (Nokia - CA)" 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>
From: Xiang Li 
Message-ID: <57880A98.1020702@seguesoft.com>
Date: Thu, 14 Jul 2016 16:56:40 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 21:57:09 -0000

Hi
 >...
 > NP containers cannot be created/deleted in a deeper sense of the word 
since they have zero information content.
 > They can only be referred to.

So the operation on a NP container element carries no meaning?
I don't find RFC6020 says the "None" operation on a NP container should be
handled differently than other nodes.

Currently the paragraph does suggest that a  NP container
can be created/deleted explicitly, even there are no child nodes.

https://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-14.txt

7.5.  The container Statement

    7.5.8.  NETCONF  Operations

    Containers can be created, deleted, replaced, and modified through
    , by using the "operation" attribute (see [RFC6241],
    Section 7.2) in the container's XML element.

    If a container does not have a "presence" statement and the last
    child node is deleted, the NETCONF server MAY delete the container.

    When a NETCONF server processes an  request, the
    elements of procedure for the container node are:

       If the operation is "merge" or "replace", the node is created if
       it does not exist.

       If the operation is "create", the node is created if it does not
       exist.  If the node already exists, a "data-exists" error is
       returned.

       If the operation is "delete", the node is deleted if it exists.
       If the node does not exist, a "data-missing" error is returned.

-Xiang


From nobody Thu Jul 14 15:14:48 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D594E12D589 for ; Thu, 14 Jul 2016 15:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMQeW8WrzpdI for ; Thu, 14 Jul 2016 15:14:44 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AED12D17A for ; Thu, 14 Jul 2016 15:07:26 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id x130so131209301vkc.0 for ; Thu, 14 Jul 2016 15:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BNMrNFQMqgF5DAQleaXKHuKLnuUpCgGGshB5PtGKyq0=; b=XOG7pGzKrNVvcfQIOgOtVa4dP4/HM1NqLlheOTFXhFyzcVB/QfMxVtVSej5bshcAGS KXCpLTeXp9hX1dQapU96niPwdiyyqk91WHiFbOQ0xnBaJGuQqQpIhuwbfeHfUa0cYXSg +92dn6HWS8q5TntbIu85p178MInHL1hW5mZnIQke9jM/dObUk0sorr0yZX5N3pxrwExe goW4EjB2AEfvlhjXo8vfNkBqriQFt6kzPJAK7LTxYU7ezeYXUkiSVIZTVoz+MATxhPVQ 204H8KLacHqNBc9bRSu8Qm+OdmV5lJxAU69INDdjg3hnYEPY/NZVTQrcKwBJ+OUDreu0 9OUQ==
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; bh=BNMrNFQMqgF5DAQleaXKHuKLnuUpCgGGshB5PtGKyq0=; b=LkNSDJa+clW6/gzYhhe0zzxsT3ckJzI3d4KTEAMge/3wnuuy0sFsvIbexvZeaTxk+M Yum9Tcp6WkxqQI7mY2ODIWzm0GqZurerhP+pc1UDzpRfEDMAK2KOxw1ittXcxfv/Ft+w svfMzGm1g4Sheynn9LfGcx9Osh+pqRWlm4ZKRlYhwvZeOWQpImj4RXPv0PzjS6MOop7g trY5eku4Y9bcGZq8hGUC/NTXKfyt5nRxrH2o0vm2jfzQQBdDXfuT4ya6XwOhWM2K1zn8 6GDxR0vduAlyZyFRb5JiAPKujyfzNDZzKwji5eo0OcwySaFkc0fuwT/k5ILPiwbhrU41 LpuA==
X-Gm-Message-State: ALyK8tKTSuA9tV0UedJAXhozWqXL7+NpQ+U+6SLO8e411Wx0GBnzQE5nAZ38UWtS5FujKXqgmdUtPropVooWSg==
X-Received: by 10.31.9.65 with SMTP id 62mr8330768vkj.89.1468534045838; Thu, 14 Jul 2016 15:07:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 14 Jul 2016 15:07:25 -0700 (PDT)
In-Reply-To: <40DE01C9-4528-493A-A0C6-08AA4648D900@gmail.com>
References:  <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com>  <40DE01C9-4528-493A-A0C6-08AA4648D900@gmail.com>
From: Andy Bierman 
Date: Thu, 14 Jul 2016 15:07:25 -0700
Message-ID: 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=001a11440b6424a8c905379fbaba
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jul 2016 22:14:47 -0000

--001a11440b6424a8c905379fbaba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 14, 2016 at 2:53 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Jason,
>
> On Jul 14, 2016, at 1:34 PM, Sterne, Jason (Nokia - CA) <
> jason.sterne@nokia.com> wrote:
>
> Hi Mahesh,
>
> I=E2=80=99m not sure I understand your first statement.  Can you explain =
further
> ?  Are you saying that on a system that supports both writable-running an=
d
> candidate you think clients may just take the lock on the candidate, do
> their updated, commit and then release the lock ?   I think that is
> reasonable/possible.
>
>
> What I was stating was a statement of fact. Here is a typical transaction
> that I see. Notice, no effort to lock the running configuration.
>
>

>From RFC 6241, 8.2.4.1: 

         If the running or candidate configuration is currently locked
         by a different session, the  operation MUST fail with
         an  value of "in-use".



Andy

      message-id=3D"2">
>   
>     
>       
>     
>   
> 
>
>             xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>   
> 
>
>       message-id=3D"3">
>   
>     
>       
>     
>     test-then-set
>     rollback-on-error
>     
>       =E2=80=A6 config stuff
>     
>   
> 
>
>             xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>   
> 
>
>       message-id=3D"4">
>   
>     
>   
> 
>
>             xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>   
> 
>
>       message-id=3D"5">
>   
> 
>
>             xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>   
> 
>
>       message-id=3D"6">
>   
>     
>       
>     
>   
> 
>
>             xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>   
> 
>
>       message-id=3D"7">
>   
> 
>
>
>
> As for preventing other mgmnt. interfaces from interfering -> I think
> RFC6241 is reasonably clear that should be prevented:
>
> Additionally, the system
>       will ensure that these locked configuration resources will not be
>       modified by other non-NETCONF management operations such as SNMP
>       and CLI.
>
> I agree with the general workflow but the question is whether the client
> should explicitly get both locks, or whether the server side should
> implicitly take both locks (i.e. prevent separate modifications/lock of t=
he
> other DS).  It isn=E2=80=99t obvious but I lean towards the server side h=
andling
> this situation (especially since the combination of writeable-running and
> candidate support is somewhat rare).
>
> Jason
>
> *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com
> ]
> *Sent:* Thursday, July 14, 2016 16:01
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Netconf
> *Subject:* Re: [Netconf]  in a server that supports both
> writable-running and candidate
>
> I see clients acquiring lock on the candidate config but not on running.
> You are right that it does not prevent, say RESTCONF or even CLI from
> updating the running-config directly.
>
> A workflow for what should be happening is:
>
> - acquire lock on candidate and running (can create deadlock as Andy
> mentions)
> - edit the candidate config
> - validate candidate config
> - commit candidate to running
> - release lock on candidate and running
>
>
>
> On Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia - CA) <
> jason.sterne@nokia.com> wrote:
>
> Hi all,
>
> I=E2=80=99m looking for opinions on how a client & server might interact =
for the
>  RPC when a server supports both writable-running and candidate DS.
>
>
> I suspect this is an unusual situation -> does anyone out there work with
> or have a server implementation that supports both ?
>
> The spirit of a  is to reserve exclusive access to alter the
> configuration of the device, and to prevent other clients (or management
> interfaces) from altering the config in the meantime.  I realize that in
> theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant) but I th=
ink that might be
> too simplistic for a system with both writable-running and candidate.
>
> In a server that supports both writable-running & candidate, it seems to
> make sense that a  of the running DS would also cause the server to
> implicitly lock the candidate (or at least reject a lock request of the
> candidate).  Otherwise (i.e. accepting a subsequent lock of the candidate=
)
> the client may assume since it has the candidate lock then it has the
> exclusive rights to the config and can happily edit & commit the config.
> It would be confusing to error on the commit (due to locking) after havin=
g
> accepted a lock.
>
> Similarly for the reverse situation -> if a client takes a candidate
>  then couldn=E2=80=99t it assume that nobody can subsequently block=
 their
> commit by taking a lock of the running DS ?
>
> It seems like the server should manage this interaction and avoid giving
> an =E2=80=9COK=E2=80=9D to clients taking the two locks on the two datast=
ores.
>
> On the other hand this could all be left up to the clients to deal with.
> Clients would have to see that a server has both a writeable-running and =
a
> candidate DS and take a lock of both.   But that would require all client=
s
> to have that behavior (instead of the server that supports the 2 DSes
> dealing with this).  It also has race conditions where the client takes 1
> lock but someone else gets the second lock.
>
> Opinions appreciated.
> Regards,
> Jason
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--001a11440b6424a8c905379fbaba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 14, 2016 at 2:53 PM, Mahesh Jethanandani =
<mjethanand=
ani@gmail.com> wrote:
Jason,

On Jul =
14, 2016, at 1:34 PM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:=


Hi Mahesh,
=C2=A0
I=E2=80=99m not sure I understand your first statement.=C2=A0 Can you ex=
plain further ?=C2=A0 Are you saying that on a system that supports both wr=
itable-running and candidate you think clients may just take the lock on th=
e candidate, do their updated, commit and then release the lock ?=C2=A0=C2=
=A0 I think that is reasonable/possible.

What I was stating was a statement of fact. Here is a typ=
ical transaction that I see. Notice, no effort to lock the running configur=
ation.



From RFC 6241, 8.2.4.1: <=
;commit>

         If the running or candidate configuration is currently locked
         by a different session, the <commit> operation MUST fail wit=
h
         an <error-tag> value of "in-use".



Andy

<r=
pc xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
=
=C2=A0 =C2=A0 =C2=A0message-id=3D"2">
=C2=A0 <loc=
k>
=C2=A0 =C2=A0 <target>
=C2=A0 =C2=A0 =C2=A0=
 <candidate/>
=C2=A0 =C2=A0 </target>
=C2=
=A0 </lock>
</rpc>

<rpc-r=
eply message-id=3D=E2=80=9C2"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">=
;
=C2=A0 <ok/>
</rpc-reply>

<=
/div>
<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&quo=
t;
=C2=A0 =C2=A0 =C2=A0message-id=3D"3">
=
=C2=A0 <edit-config xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base=
:1.0">
=C2=A0 =C2=A0 <target>
=C2=A0 =C2=
=A0 =C2=A0 <candidate/>
=C2=A0 =C2=A0 </target>
=

=C2=A0 =C2=A0 <test-option>test-then-set</test-option>=
;
=C2=A0 =C2=A0 <error-option>rollback-on-error</error-o=
ption>
=C2=A0 =C2=A0 <config>
=C2=A0 =C2=A0 =
=C2=A0 =E2=80=A6 config stuff
=C2=A0 =C2=A0 </config>
=

=C2=A0 </edit-config>
</rpc>

<rpc-reply message-id=3D"3"
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1=
.0">
=C2=A0 <ok/>
</rpc-reply>

<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf:b=
ase:1.0"
=C2=A0 =C2=A0 =C2=A0message-id=3D"4"><=
/div>
=C2=A0 <commit>
=C2=A0 =C2=A0 <confirmed/><=
/div>
=C2=A0 </commit>
</rpc>

<rpc-reply message-id=3D"4"
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:netc=
onf:base:1.0">
=C2=A0 <ok/>
</rpc-repl=
y>

<rpc xmlns=3D"urn:ietf:params:xml:ns=
:netconf:base:1.0"
=C2=A0 =C2=A0 =C2=A0message-id=3D"5&=
quot;>
=C2=A0 <commit/>
</rpc>

<rpc-reply message-id=3D"5"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:=
netconf:base:1.0">
=C2=A0 <ok/>
</rpc-=
reply>

<rpc xmlns=3D"urn:ietf:par=
ams:xml:ns:netconf:base:1.0"
=C2=A0 =C2=A0 =C2=A0message-id=
=3D"6">
=C2=A0 <unlock>
=C2=A0 =C2=
=A0 <target>
=C2=A0 =C2=A0 =C2=A0 <candidate/>
<=
div>=C2=A0 =C2=A0 </target>
=C2=A0 </unlock>
</rpc>

<rpc-reply message-id=3D"6&=
quot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:=
ietf:params:xml:ns:netconf:base:1.0">
=C2=A0 <ok/><=
/div>
</rpc-reply>

<rpc xmlns=3D=
"urn:ietf:params:xml:ns:netconf:base:1.0"
=C2=A0 =C2=A0=
 =C2=A0message-id=3D"7">
=C2=A0 <close-session/&g=
t;
</rpc>


=C2=A0
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">As for preventing other mgmnt. interfaces from interfering -> I t=
hink RFC6241 is reasonably clear that should be prevented:
=C2=A0
<=
div style=3D"margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:'=
Times New Roman',serif">Additionally, the system<=
/span>
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 will ensure that these locked configuration resources will not be=

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 modified by other non-NETCONF management operations such=
 as SNMP
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 and CLI.
=C2=A0
I agree with the general workflow but the question is whether the=
 client should explicitly get both locks, or whether the server side should=
 implicitly take both locks (i.e. prevent separate modifications/lock of th=
e other DS).=C2=A0 It isn=E2=80=99t obvious but I lean towards the server s=
ide handling this situation (especially since the combination of writeable-=
running and candidate support is somewhat rare).
=

=C2=A0
Jason
=C2=A0
From:=C2=A0Mahesh Jethanandani [mailto:mjethanandan=
i@gmail.com]=C2=A0
Sent:=C2=A0Thurs=
day, July 14, 2016 16:01
To:=C2=A0Sterne, Jason (Nok=
ia - CA)
Cc:=C2=A0Netconf
Subject:=
=C2=A0Re: [Netconf] <lock> in a server that supports both writ=
able-running and candidate
=C2=A0
I see cl=
ients acquiring lock on the candidate config but not on running. You are ri=
ght that it does not prevent, say RESTCONF or even CLI from updating the ru=
nning-config directly.
=C2=A0
A workflow for=
 what should be happening is:
=C2=A0
- acqui=
re lock on candidate and running (can create deadlock as Andy mentions)<=
/u>
- edit the candidate conf=
ig
- validate candidat=
e config
- commit cand=
idate to running
- rel=
ease lock on candidate and running
=C2=A0
=
=C2=A0
On Jul 14, 2016, at 12:03 PM, Sterne, Jason=
 (Nokia - CA) <jason.sterne@nokia.com<=
/a>> wrote:
It seems like the server should manage this interaction and av=
oid giving an =E2=80=9COK=E2=80=9D to clients taking the two locks on the t=
wo datastores.
=C2=A0=

Mahesh Jethanand=
ani



Mahesh Jethanandani









_________________________________________=
______

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a11440b6424a8c905379fbaba--


From nobody Thu Jul 14 18:05:54 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8A12D6AD for ; Thu, 14 Jul 2016 18:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHpMK-QcEOc7 for ; Thu, 14 Jul 2016 18:05:52 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D311112D846 for ; Thu, 14 Jul 2016 18:05:51 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id t190so35213697pfb.3 for ; Thu, 14 Jul 2016 18:05:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:message-id:date:to:mime-version; bh=6B8nOCeX5vZHGfYzRIUbB2OzK7ZrCidv0gdbSpLx02E=; b=CFKKiF304jHI+CXycb+UqAcd1bVnXYwbj7SVOywFkUSbapGOrFLDJ9p0PBCF287FMz hLCH/M4MiLBxZqTnL8hp01PareIgBbnrhOgQoVZIrauu+Fu2eO+gnLmxXXw4F75G8Igs TmFJWbHQhXeuee6Rkvvclrsut+i6Spq07O9utbpDIDmVtj3KCmURyFXGiGToZOLi/96+ qg1mREOAUiDdgOIFMtLUntOb3DOxtc/3OyRwjiBk7yYk59Uvdp6pI4GfeUT1fDOsiB9S B9P9bxpieBVYB1MlK+pxlCEcR50mp5QyZWgCXmOswJrJCrPN3a820HAyvV8Tdky7EHu6 1hgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=6B8nOCeX5vZHGfYzRIUbB2OzK7ZrCidv0gdbSpLx02E=; b=K812TOpRNr8hcJ48D3CR//kykzgtxWPZcPrVi44c1nygcHK1kBB12Yw03pWgejBr9i jc8NQ953lcGedGJBJnJYbV5eyVGVxESVJ2Vo4yUuUD9tAJf8aZo8Jub+1u0eHwSzRLKc jHp7Q2sK8V64+OgG+mdfOFVhB9t6j8DZp28cQrS+8yafeBm2HweXofbZSrYpax8/Vqn0 W1em4nfYYyBqvRrA6vg7PVnWDfLf+Cnt1nCk4I+cSzPTidh8oQUk2NxyzILTCqVBdsTs UQ8+V8Z5l3cfylk/LxqkYDYITkKSd874pJALe+0jKy2zefYm2P6865cPXwxA3KU2kskq mZlA==
X-Gm-Message-State: ALyK8tKIS8FC6r8N8k4DJfhBe4wM/yk7NfFDbmEpJdxOV/PpqygDAc5Q6yjWytGfN+axnQ==
X-Received: by 10.98.47.129 with SMTP id v123mr17049610pfv.71.1468544751268; Thu, 14 Jul 2016 18:05:51 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1003::6a6? ([2001:420:c0c8:1003::6a6]) by smtp.gmail.com with ESMTPSA id cp3sm7425862pad.12.2016.07.14.18.05.49 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 18:05:49 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_36470742-4B5F-4D36-B44C-A4AB048A5897"
Message-Id: <4ACAF993-4557-4001-B104-AE469BBE94BA@gmail.com>
Date: Thu, 14 Jul 2016 18:05:47 -0700
To: Netconf 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [Netconf] Meeting next week
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 01:05:53 -0000

--Apple-Mail=_36470742-4B5F-4D36-B44C-A4AB048A5897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

NETCONF meets next week on Wednesday from 10-12:30 in Potsdam II.

The agenda for the meeting has been posted here =
. If we =
are missing anything or anyone on the agenda, please let Mehmet or I =
know.

We will be using Etherpad to take meeting notes. The link can be found =
here =
. We need volunteers for note taking and they do not even =
have to be local.

Here are the links to Audio =
, Meetecho =
, and Jabber =
. We will be looking for volunteers =
for Jabber scribe also.

If you are presenting, please send in your draft slides by Sunday.

See you on Wednesday.

Mahesh & Mehmet.





--Apple-Mail=_36470742-4B5F-4D36-B44C-A4AB048A5897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

NETCONF meets next week on Wednesday from 10-12:30 in Potsdam =
II.

The agenda for =
the meeting has been posted here. If we are missing anything or anyone on the agenda, =
please let Mehmet or I know.

We will be using Etherpad to take =
meeting notes. The link can be found here. We need volunteers for note =
taking and they do not even have to be local.

Here are the links to Audio, Meetecho, =
and Jabber. We will be looking for volunteers for Jabber =
scribe also.

If =
you are presenting, please send in your draft slides by =
Sunday.

See =
you on Wednesday.



Mahesh & Mehmet.







=

--Apple-Mail=_36470742-4B5F-4D36-B44C-A4AB048A5897--


From nobody Thu Jul 14 23:47:08 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED82912B042 for ; Thu, 14 Jul 2016 23:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z_KUV6J35v4C for ; Thu, 14 Jul 2016 23:47:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB28512B02B for ; Thu, 14 Jul 2016 23:47:03 -0700 (PDT)
Received: from [10.61.254.150] (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 6440C1AE03DD; Fri, 15 Jul 2016 08:46:38 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A7397ABF-F3D7-46FB-B0C0-3468B176965D"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: 
Date: Fri, 15 Jul 2016 08:46:04 +0200
Message-Id: <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> 
To: Andy Bierman , Xiang Li , "Sterne, Jason (Nokia - CA)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 06:47:07 -0000

--Apple-Mail=_A7397ABF-F3D7-46FB-B0C0-3468B176965D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_13B85A16-6118-4E60-8636-5F576A60786E"


--Apple-Mail=_13B85A16-6118-4E60-8636-5F576A60786E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In order to reach rough consensus on the interpretation of the =
default-operation=3Dnone sequence, I think we need to start with coming =
to a common understanding of what NP containers are. Can NP containers =
be "created" and "deleted" just like P containers?

Here's a test to see if there is any difference between the behavior of =
p and np containers:

list t {
    key a;
    leaf a { type uint32; }
    container np {
        must "../a > 10";
    }
    container p {
        presence "...";
        must "../a > 20";
    }
}

The config is initially empty. Now, would it be possible to

a) create an instance with a =3D 5 if there is no mention of np and p in =
the edit-config?
b) create an instance with a =3D 5 if np (but not p) is "created" in the =
edit-config?
c) create an instance with a =3D 15 if there is no mention of np and p =
in the edit-config?
d) create an instance with a =3D 15 if p is created in the edit-config?

My own answer is that only operation c is allowed. "creation" of an NP =
container is irrelevant, while creation of a P container makes a =
difference. An NP container is simply a structural element, and does not =
need to be "created" to exist, but empty NP containers MAY not be =
reported since they are meaningless anyway.

If must statements in np containers are in effect even if the client =
isn't explicitly "creating" or mentioning the container, then I find it =
hard to understand the viewpoint that "creation" of NP containers makes =
any difference.

/jan

>> I guess I don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=
=9D.  They are just structure and filtered out when empty.  I don=E2=80=99=
t really see this as the server =E2=80=9Cdeleting=E2=80=9D those =
containers.  It just suppresses them in  output.
>>=20
>> Please show me the RFC text that says the server can filter out NP =
containers.
>> All config=3Dtrue data nodes are config.
>=20
> In a very technical sense, I suppose the above statement is correct. =
An NP container is of course config true if it sits in the config true =
part of the tree. At the same time I agree with Janson's view that NP =
containers are just structure, so the question of their "existence" is =
moot.
>=20
> Here's what RFC 6020, sec 7.5 says on the topic:
>=20
>    YANG supports two styles of containers, those that exist only for
>    organizing the hierarchy of data nodes, and those whose presence in
>    the configuration has an explicit meaning.
>=20
> So NP containers "exist only for organizing the hierarchy" while a P =
container "has an explicit meaning". I guess this implies NP containers =
having no meaning. Further down in 7.5.1, re P containers, it is noted =
that:
>=20
>    In the second style, the presence of the container itself is
>    configuration data, representing a single bit of configuration =
data.
>    The container acts as both a configuration knob and a means of
>    organizing related configuration.  These containers are explicitly
>    created and deleted.
>=20
> Based on these fragments, I conclude that NP containers have zero bits =
of information. This means the existence/absence of an NP container =
cannot be known/stored/remembered even internally by a conforming =
system. The existence/absence of an NP container is a moot question. =
It's a bit like asking for the value of a void function. It's there, it =
has a name, but no value.
>=20
> Implementations that receive a  or  request that =
contains an NP container will have to decide whether to include the NP =
container in the response or not. Since the existence of the NP =
container cannot be read from a database/etc (it has zero bits of =
information), the implementation will have to use some other way to =
determine whether to include it or not.
>=20
> In order to make the life easier for implementors, the following MAY =
was introduced in sec 7.5.7:
>=20
>    A NETCONF server that replies to a  or  request =
MAY
>    choose not to send a container element if the container node does =
not
>    have the "presence" statement and no child nodes exist.
>=20
> So the NP container has to be included if it has children, or else the =
structural function of the container would be lost. If the NP container =
is empty, it may or may not be sent. Since an NP container has zero bits =
of information, this decision would not be based on whether it has been =
previously "created" or "deleted", but on implementation considerations. =
One possible approach is to always include it, another to actually check =
if there are any children, and only return it then.
>=20
> Either way, NP containers alone have no meaning/information, they are =
only there for structure.
>=20
>> A false must-stmt in an NP-container is still an error.
>=20
> Certainly. Must statements on an NP container are always evaluated, =
even if the container hasn't been "created" or mentioned by a client, =
and even if it has no child elements.
>=20
>> As Lada has pointed out many times, the text about
>> NP containers not being part of the data model is just wrong.
>=20
> I think the length of this discussion implies we should include this =
topic in the upcoming YANG FAQ.
>> The server should not error in the cases Mahesh & Einar show -> the =
presence/existence of NP-containers shouldn=E2=80=99t really affect =
behavior (since they aren=E2=80=99t really config).
>>=20
> I agree with the above.
>> But I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs =
to guard=E2=80=9D.  Do you agree that the server should not error in =
those cases below ?
>>=20
>> The YANG text says a server MAY delete an empty NP container.
>> Using default-operation=3Dnone implies that the client is sure the =
nodes for operation=3Dnone
>> actually exist.  Because of this YANG detail, the client cannot be =
sure so using
>> default-operation=3Dnone may not work.
>=20
> I disagree with this conclusion. Even using default-operation=3Dnone =
the transactions must be guaranteed to work by a conforming =
implementation. NP containers cannot be created/deleted in a deeper =
sense of the word since they have zero information content. They can =
only be referred to. Any must statements within the container must be =
evaluated regardless of the client ever mentioning the container.
>=20
>=20
>=20
> I do not agree that default-operation=3Dnone does not apply to NP =
containers.
>=20
> This is why it was such a bad decision to spread little pieces of =
NETCONF
> all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
> and it does not say anything about special treatment for NP =
containers.
>=20
>    none:  The target datastore is unaffected by the configuration
>             in the  parameter, unless and until the incoming
>             configuration data uses the "operation" attribute to =
request
>             a different operation.  If the configuration in the =

>             parameter contains data for which there is not a
>             corresponding level in the target datastore, an =

>             is returned with an  value of data-missing.
>             Using "none" allows operations like "delete" to avoid
>             unintentionally creating the parent hierarchy of the =
element
>             to be deleted.
>=20
>=20
> /jan
>=20
>=20
> Andy


--Apple-Mail=_13B85A16-6118-4E60-8636-5F576A60786E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In order to reach rough consensus on the interpretation of =
the default-operation=3Dnone sequence, I think we need to start with =
coming to a common understanding of what NP containers are. Can NP =
containers be "created" and "deleted" just like P containers?

Here's a test to see if =
there is any difference between the behavior of p and np =
containers:

list=
 t {
    key a;
 =
   leaf a { type uint32; }
    =
container np {
        must =
"../a > 10";
    }
    container p {
  =
      presence "...";
    =
    must "../a > 20";
    =
}
}

The config is initially empty. Now, would it be possible =
to

a) create =
an instance with a =3D 5 if there is no mention of np and p in the =
edit-config?
b) create an instance with a =3D 5 if =
np (but not p) is "created" in the edit-config?
c) =
create an instance with a =3D 15 if there is no mention of np and p in =
the edit-config?
d) create an instance with a =3D =
15 if p is created in the edit-config?

My own answer is =
that only operation c is allowed. "creation" of an NP container is =
irrelevant, while creation of a P container makes a difference. An NP =
container is simply a structural element, and does not need to be =
"created" to exist, but empty NP containers MAY not be reported since =
they are meaningless anyway.

If must statements in np containers are =
in effect even if the client isn't explicitly "creating" or mentioning =
the container, then I find it hard to understand the viewpoint that =
"creation" of NP containers makes any difference.
/jan

I guess I =
don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=9D.  =
They are just structure and filtered out when empty.  I don=E2=80=99t=
 really see this as the server =E2=80=9Cdeleting=E2=80=9D those =
containers.  It just suppresses them in <get-config> output. =
  
Please show me the RFC text that says the server can filter =
out NP containers.
All config=3Dtrue data nodes are =
config.

In a very technical sense, I suppose =
the above statement is correct. An NP container is of course config true =
if it sits in the config true part of the tree. At the same time I agree =
with Janson's view that NP containers are just structure, so the =
question of their "existence" is moot. 

Here's what RFC 6020, sec 7.5 says on =
the topic:

   YANG supports two styles of =
containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.


So NP =
containers "exist only for organizing the hierarchy" while a P container =
"has an explicit meaning". I guess this implies NP containers having no =
meaning. Further down in 7.5.1, re P containers, it is noted =
that:

   In the second style, the presence of =
the container itself is
   configuration data, representing a single bit of configuration data.

   The =
container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.


Based on these fragments, I conclude that NP containers have =
zero bits of information. This means the existence/absence of an NP =
container cannot be known/stored/remembered even internally by a =
conforming system. The existence/absence of an NP container is a moot =
question. It's a bit like asking for the value of a void function. It's =
there, it has a name, but no value.

Implementations that receive a =
<get> or <get-config> request that contains an NP container =
will have to decide whether to include the NP container in the response =
or not. Since the existence of the NP container cannot be read from a =
database/etc (it has zero bits of information), the implementation will =
have to use some other way to determine whether to include it or =
not.

In order =
to make the life easier for implementors, the following MAY was =
introduced in sec 7.5.7:

   A NETCONF server =
that replies to a <get> or <get-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.

So the NP =
container has to be included if it has children, or else the structural =
function of the container would be lost. If the NP container is empty, =
it may or may not be sent. Since an NP container has zero bits of =
information, this decision would not be based on whether it has been =
previously "created" or "deleted", but on implementation considerations. =
One possible approach is to always include it, another to actually check =
if there are any children, and only return it then.

Either way, NP =
containers alone have no meaning/information, they are only there for =
structure.

A false must-stmt in an =
NP-container is still an error.

Certainly. Must =
statements on an NP container are always evaluated, even if the =
container hasn't been "created" or mentioned by a client, and even if it =
has no child elements.

As Lada has pointed out many =
times, the text about
NP containers not being part =
of the data model is just =
wrong.

I think the length of this discussion =
implies we should include this topic in the upcoming YANG =
FAQ.
The=
 server should not error in the cases Mahesh & Einar show -> the =
presence/existence of NP-containers shouldn=E2=80=99t really affect =
behavior (since they aren=E2=80=99t really config). 
I agree with the above.
But=
 I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs to =
guard=E2=80=9D.  Do you agree that the server should not error in =
those cases below ?
The=
 YANG text says a server MAY delete an empty NP container.
Using default-operation=3Dnone implies that the client is =
sure the nodes for operation=3Dnone
actually =
exist.  Because of this YANG detail, the client cannot be sure so =
using
default-operation=3Dnone may not =
work.

I disagree with this conclusion. Even =
using default-operation=3Dnone the transactions must be guaranteed to =
work by a conforming implementation. NP containers cannot be =
created/deleted in a deeper sense of the word since they have zero =
information content. They can only be referred to. Any must statements =
within the container must be evaluated regardless of the client ever =
mentioning the container.



I do not agree that default-operation=3Dnone does not apply =
to NP containers.

This is why it was such a bad decision to spread little =
pieces of NETCONF
all over the YANG RFC. RFC 6241 =
defines the 'default-operation' leaf
and it does =
not say anything about special treatment for NP containers.

   none:  The target =
datastore is unaffected by the configuration
            in the <config> parameter, unless and until the =
incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the =
<config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an =
<rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


 
/jan


Andy

=

--Apple-Mail=_13B85A16-6118-4E60-8636-5F576A60786E--

--Apple-Mail=_A7397ABF-F3D7-46FB-B0C0-3468B176965D
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

iQEcBAEBCgAGBQJXiIasAAoJEBSCnbqufIisVUIH/3O97xyq4rLlKUhivOQkvrge
t9wVL7iAjLywxHu5vN3skYB8qu+5JW9wwqncK79XtVt04lsvCDC0W2rbhs7+nsJW
w4VbZOi3JzdLbqAKuhX2sIvFCC9IOxdF3zLkTMIdQ4b0YEGzjzxJ1WTzcbO38LCY
I3cF45IaDOjvaaIGaTByQDvGwnYCy5nHuA2YJTtHRgCivaxlx1KyCrwgKt3tjGAT
bp8oSDAfYgyoGM9csxZmwc4/5gIC4BR+J6S8XHTF7kHzHNigSsm4jlwKobIAERRu
EjqicULwl7SW0Phc3v4a0TOINbJuRKSp/UffJM45aq9cfhcn5qGhMRkj0OJ0SaQ=
=mV3L
-----END PGP SIGNATURE-----

--Apple-Mail=_A7397ABF-F3D7-46FB-B0C0-3468B176965D--


From nobody Fri Jul 15 00:24:58 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8C812D094 for ; Fri, 15 Jul 2016 00:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1dcioVGQX_L for ; Fri, 15 Jul 2016 00:24:54 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8159A12B057 for ; Fri, 15 Jul 2016 00:24:53 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id j126so89982272vkg.3 for ; Fri, 15 Jul 2016 00:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GHE1j5HvU3NLzkf/Sk8cejvNlxx0LkyOOuhYPsc9u3w=; b=id2M01Z3xCW88hGmmZpkoVC4R05++/nfr94H01N38vDTeFors5a/L2zgsW1uoyMEHv OVJ2VaQkHA1707INLTrAk7ZRZRWkhxuKsPO5zDwgo7e65wZwgMDx3nCa6ifi0TBKLO6W kwWNEzm2LPDIW4DG7HosmwErfSyxKlXMd8vNLLX6fi2LGWLo0u8x7qpePOOR1rmGDix8 hB8PZ7W7pHZM73gItDoML7rRDOB24aM9Q///nJmod8/jKz3Os2pgnnjRJDp6h/Xmfxsl r5ze9nx64mZY/m2O/m6mKFc/gKpUKGNDtukLM/NMXs0XWwNwRyIL4oGh8uzgKVHNe8Ju zlpQ==
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; bh=GHE1j5HvU3NLzkf/Sk8cejvNlxx0LkyOOuhYPsc9u3w=; b=lrFLMcYZx1gC/kZOyCPw9yDax24K6N2L29qFm/CCeoP9jMfzWA6XwJh6BEIMhOnwLa eVvzjoS1V3VbV4rcFikJv8picD5uVQ0YslhKPV09nAboXjL08qnNFmUD/vIoDjGx3J5X 473T9S4i4VjBfM0WK+6xi3fIFdszwzqbt2LDaaU6syMx5VhC53Vuuki6NntOE1TcNzMB tDIDRYG+ge8qK//NTpFjLSgu15oN3uDIKw/chGctWdcuuHc/sZ3i1bkaAkAAKjcVTYRW KgvQB2TowW0FRuiiVo2gE0Q8cEavi4Nsce6imxzAriEbNTglGsuE8OEKiTv7UaRPQAZ8 4EOQ==
X-Gm-Message-State: ALyK8tKggEgnuf97omlGSVS4hrwels4KT6+n13k0qUAW36IP7nCQ1zS5Rwj3iCa4Mft8maRVhY7+YR6OZntGFA==
X-Received: by 10.176.69.161 with SMTP id u30mr9195349uau.135.1468567492534; Fri, 15 Jul 2016 00:24:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Fri, 15 Jul 2016 00:24:51 -0700 (PDT)
In-Reply-To: <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com>
From: Andy Bierman 
Date: Fri, 15 Jul 2016 00:24:51 -0700
Message-ID: 
To: Jan Lindblad 
Content-Type: multipart/alternative; boundary=94eb2c11c960b8bdfb0537a7832b
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 07:24:56 -0000

--94eb2c11c960b8bdfb0537a7832b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I do not like NP containers at all.
They have so many special rules.
I don't know what problem is being solved by having them at all.
Also RFC 6241 defines NETCONF, not YANG.

Even in the YANG 1.1 spec, it says MAY delete but does not say MAY create
anywhere.
YANG does not say NP containers cannot be created or deleted
by the client.


Andy


On Thu, Jul 14, 2016 at 11:46 PM, Jan Lindblad  wrote:

> In order to reach rough consensus on the interpretation of the
> default-operation=3Dnone sequence, I think we need to start with coming t=
o a
> common understanding of what NP containers are. Can NP containers be
> "created" and "deleted" just like P containers?
>
> Here's a test to see if there is any difference between the behavior of p
> and np containers:
>
> list t {
>     key a;
>     leaf a { type uint32; }
>     container np {
>         must "../a > 10";
>     }
>     container p {
>         presence "...";
>         must "../a > 20";
>     }
> }
>
> The config is initially empty. Now, would it be possible to
>
> a) create an instance with a =3D 5 if there is no mention of np and p in =
the
> edit-config?
> b) create an instance with a =3D 5 if np (but not p) is "created" in the
> edit-config?
> c) create an instance with a =3D 15 if there is no mention of np and p in
> the edit-config?
> d) create an instance with a =3D 15 if p is created in the edit-config?
>
> My own answer is that only operation c is allowed. "creation" of an NP
> container is irrelevant, while creation of a P container makes a
> difference. An NP container is simply a structural element, and does not
> need to be "created" to exist, but empty NP containers MAY not be reporte=
d
> since they are meaningless anyway.
>
> If must statements in np containers are in effect even if the client isn'=
t
> explicitly "creating" or mentioning the container, then I find it hard to
> understand the viewpoint that "creation" of NP containers makes any
> difference.
>
> /jan
>
> I guess I don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=
=9D.  They are just
>>> structure and filtered out when empty.  I don=E2=80=99t really see this=
 as the
>>> server =E2=80=9Cdeleting=E2=80=9D those containers.  It just suppresses=
 them in
>>>  output.
>>>
>> Please show me the RFC text that says the server can filter out NP
>> containers.
>> All config=3Dtrue data nodes are config.
>>
>>
>> In a very technical sense, I suppose the above statement is correct. An
>> NP container is of course config true if it sits in the config true part=
 of
>> the tree. At the same time I agree with Janson's view that NP containers
>> are just structure, so the question of their "existence" is moot.
>>
>> Here's what RFC 6020, sec 7.5 says on the topic:
>>
>>    YANG supports two styles of containers, those that exist only for
>>    organizing the hierarchy of data nodes, and those whose presence in
>>    the configuration has an explicit meaning.
>>
>>
>> So NP containers "exist only for organizing the hierarchy" while a P
>> container "has an explicit meaning". I guess this implies NP containers
>> having no meaning. Further down in 7.5.1, re P containers, it is noted t=
hat:
>>
>>    In the second style, the presence of the container itself is
>>    configuration data, representing a single bit of configuration data.
>>
>>    The container acts as both a configuration knob and a means of
>>    organizing related configuration.  These containers are explicitly
>>    created and deleted.
>>
>>
>> Based on these fragments, I conclude that NP containers have zero bits o=
f
>> information. This means the existence/absence of an NP container cannot =
be
>> known/stored/remembered even internally by a conforming system. The
>> existence/absence of an NP container is a moot question. It's a bit like
>> asking for the value of a void function. It's there, it has a name, but =
no
>> value.
>>
>> Implementations that receive a  or  request that
>> contains an NP container will have to decide whether to include the NP
>> container in the response or not. Since the existence of the NP containe=
r
>> cannot be read from a database/etc (it has zero bits of information), th=
e
>> implementation will have to use some other way to determine whether to
>> include it or not.
>>
>> In order to make the life easier for implementors, the following MAY was
>> introduced in sec 7.5.7:
>>
>>    A NETCONF server that replies to a  or  request MAY
>>    choose not to send a container element if the container node does not
>>    have the "presence" statement and no child nodes exist.
>>
>>
>> So the NP container has to be included if it has children, or else the
>> structural function of the container would be lost. If the NP container =
is
>> empty, it may or may not be sent. Since an NP container has zero bits of
>> information, this decision would not be based on whether it has been
>> previously "created" or "deleted", but on implementation considerations.
>> One possible approach is to always include it, another to actually check=
 if
>> there are any children, and only return it then.
>>
>> Either way, NP containers alone have no meaning/information, they are
>> only there for structure.
>>
>> A false must-stmt in an NP-container is still an error.
>>
>>
>> Certainly. Must statements on an NP container are always evaluated, even
>> if the container hasn't been "created" or mentioned by a client, and eve=
n
>> if it has no child elements.
>>
>> As Lada has pointed out many times, the text about
>> NP containers not being part of the data model is just wrong.
>>
>>
>> I think the length of this discussion implies we should include this
>> topic in the upcoming YANG FAQ.
>>
>> The server should not error in the cases Mahesh & Einar show -> the
>>> presence/existence of NP-containers shouldn=E2=80=99t really affect beh=
avior (since
>>> they aren=E2=80=99t really config).
>>>
>> I agree with the above.
>>
>> But I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs to =
guard=E2=80=9D.  Do you
>>> agree that the server should not error in those cases below ?
>>>
>> The YANG text says a server MAY delete an empty NP container.
>> Using default-operation=3Dnone implies that the client is sure the nodes
>> for operation=3Dnone
>> actually exist.  Because of this YANG detail, the client cannot be sure
>> so using
>> default-operation=3Dnone may not work.
>>
>>
>> I disagree with this conclusion. Even using default-operation=3Dnone the
>> transactions must be guaranteed to work by a conforming implementation. =
NP
>> containers cannot be created/deleted in a deeper sense of the word since
>> they have zero information content. They can only be referred to. Any mu=
st
>> statements within the container must be evaluated regardless of the clie=
nt
>> ever mentioning the container.
>>
>>
>
> I do not agree that default-operation=3Dnone does not apply to NP contain=
ers.
>
> This is why it was such a bad decision to spread little pieces of NETCONF
> all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
> and it does not say anything about special treatment for NP containers.
>
>    none:  The target datastore is unaffected by the configuration
>             in the  parameter, unless and until the incoming
>             configuration data uses the "operation" attribute to request
>             a different operation.  If the configuration in the 
>             parameter contains data for which there is not a
>             corresponding level in the target datastore, an 
>             is returned with an  value of data-missing.
>             Using "none" allows operations like "delete" to avoid
>             unintentionally creating the parent hierarchy of the element
>             to be deleted.
>
>
>
>
>> /jan
>>
>>
> Andy
>
>
>

--94eb2c11c960b8bdfb0537a7832b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I do not like NP containers at all.=

They have so many special rules.
I don't know what=
 problem is being solved by having them at all.
Also RFC 6241 def=
ines NETCONF, not YANG.

Even in the YANG 1.1 spec,=
 it says MAY delete but does not say MAY create anywhere.
YANG do=
es not say NP containers cannot be created or deleted
by the =
client.


Andy


On Thu, Jul 1=
4, 2016 at 11:46 PM, Jan Lindblad <janl@tail-f.com> wrote:
=

In order=
 to reach rough consensus on the interpretation of the default-operation=3D=
none sequence, I think we need to start with coming to a common understandi=
ng of what NP containers are. Can NP containers be "created" and =
"deleted" just like P containers?

Here's a=
 test to see if there is any difference between the behavior of p and np co=
ntainers:

list t {
=C2=A0 =C2=A0 key a;<=
/div>
=C2=A0 =C2=A0 leaf a { type uint32; }
=C2=A0 =C2=A0 con=
tainer np {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 must "../a > 10&q=
uot;;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 container p {
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 presence "...";
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 must "../a > 20";
=C2=A0 =C2=
=A0 }
}

The config is initially empty. N=
ow, would it be possible to

a) create an instance =
with a =3D 5 if there is no mention of np and p in the edit-config?
b) create an instance with a =3D 5 if np (but not p) is "created&qu=
ot; in the edit-config?
c) create an instance with a =3D 15 if th=
ere is no mention of np and p in the edit-config?
d) create an in=
stance with a =3D 15 if p is created in the edit-config?
My own answer is that only operation c is allowed. "=
creation" of an NP container is irrelevant, while creation of a P cont=
ainer makes a difference. An NP container is simply a structural element, a=
nd does not need to be "created" to exist, but empty NP container=
s MAY not be reported since they are meaningless anyway.

If must statements in np containers are in effect even if the client=
 isn't explicitly "creating" or mentioning the container, the=
n I find it hard to understand the viewpoint that "creation" of N=
P containers makes any difference.

/jan
=

I guess I don=E2=80=99t really se=
e NP-containers as =E2=80=9Cconfig=E2=80=9D.=C2=A0 They are just structure =
and filtered out when empty.=C2=A0 I don=E2=80=99t really see this as the s=
erver =E2=80=9Cdeleting=E2=80=9D those containers.=C2=A0 It just suppresses=
 them in <get-config> output. =C2=A0=C2=A0
<=
/div>
Please show me the RFC text that says the serv=
er can filter out NP containers.
All config=3Dtrue data nodes are=
 config.

In a very =
technical sense, I suppose the above statement is correct. An NP container =
is of course config true if it sits in the config true part of the tree. At=
 the same time I agree with Janson's view that NP containers are just s=
tructure, so the question of their "existence" is moot.=C2=A0

Here's what RFC 6020, sec 7.5 says on the topic:<=
/div>

   YANG supports two styles of contain=
ers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.


So NP containers "exist only for organ=
izing the hierarchy" while a P container "has an explicit meaning=
". I guess this implies NP containers having no meaning. Further down =
in 7.5.1, re P containers, it is noted that:

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.

   The container acts as both a configuration knob a=
nd a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.


Based on these fragments, I conclude =
that NP containers have zero bits of information. This means the existence/=
absence of an NP container cannot be known/stored/remembered even internall=
y by a conforming system. The existence/absence of an NP container is a moo=
t question. It's a bit like asking for the value of a void function. It=
's there, it has a name, but no value.

Impleme=
ntations that receive a <get> or <get-config> request that cont=
ains an NP container will have to decide whether to include the NP containe=
r in the response or not. Since the existence of the NP container cannot be=
 read from a database/etc (it has zero bits of information), the implementa=
tion will have to use some other way to determine whether to include it or =
not.

In order to make the life easier for implemen=
tors, the following MAY was introduced in sec 7.5.7:

   A NETCONF server that replies to a <get> or <get=
-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.
<=
div>
So the NP container has to be included if it has c=
hildren, or else the structural function of the container would be lost. If=
 the NP container is empty, it may or may not be sent. Since an NP containe=
r has zero bits of information, this decision would not be based on whether=
 it has been previously "created" or "deleted", but on =
implementation considerations. One possible approach is to always include i=
t, another to actually check if there are any children, and only return it =
then.

Either way, NP containers alone have no mean=
ing/information, they are only there for structure.

A false must-stmt in an NP-container is still an error.
<=
/div>

Certainly. Must statement=
s on an NP container are always evaluated, even if the container hasn't=
 been "created" or mentioned by a client, and even if it has no c=
hild elements.

As Lada has pointed out =
many times, the text about
NP containers not being part of the da=
ta model is just wrong.

=

I think the length of this discussion implies we should include this t=
opic in the upcoming YANG FAQ.
=

The server should not error in the cases Mahesh & Einar sho=
w -> the presence/existence of NP-containers shouldn=E2=80=99t really af=
fect behavior (since they aren=E2=80=99t really config).=C2=
=A0
I agr=
ee with the above.
Bu=
t I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs to guard=
=E2=80=9D.=C2=A0 Do you agree that the server should not error in those cas=
es below ?
The YANG text says a ser=
ver MAY delete an empty NP container.
Using default-operation=3Dn=
one implies that the client is sure the nodes for operation=3Dnone
actually exist.=C2=A0 Because of this YANG detail, the client cannot be s=
ure so using
default-operation=3Dnone may not work.

I disagree with this conclusion.=
 Even using default-operation=3Dnone the transactions must be guaranteed to=
 work by a conforming implementation. NP containers cannot be created/delet=
ed in a deeper sense of the word since they have zero information content. =
They can only be referred to. Any must statements within the container must=
 be evaluated regardless of the client ever mentioning the container.
=




I do not agree that default-ope=
ration=3Dnone does not apply to NP containers.

Thi=
s is why it was such a bad decision to spread little pieces of NETCONF
all over the YANG RFC. RFC 6241 defines the 'default-operation=
9; leaf
and it does not say anything about special treatment for =
NP containers.

   none:  The target datastore is unaffected by the c=
onfiguration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to =
request
            a different operation.  If the configuration in the <config&=
gt;
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error&g=
t;
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete"=
; to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


=C2=A0
/j=
an


Andy




--94eb2c11c960b8bdfb0537a7832b--


From nobody Fri Jul 15 04:32:19 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0213012D73B for ; Fri, 15 Jul 2016 04:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7Ku5CK8tAoJK for ; Fri, 15 Jul 2016 04:32:15 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D876612D698 for ; Fri, 15 Jul 2016 04:32:14 -0700 (PDT)
Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 1F09FAC384F69; Fri, 15 Jul 2016 11:32:12 +0000 (GMT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6FBWCqI004335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 11:32:12 GMT
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u6FBWBgB024030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Jul 2016 11:32:11 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 15 Jul 2016 07:32:11 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Andy Bierman , Jan Lindblad 
Thread-Topic: [Netconf] What should a server response be?
Thread-Index: AQHR3esI0j4IVR1/2kW9+f8gjxD6tKAYQ0SQgABICoD//73wYIAARsmA///nJISAAKD68oAAQxig
Date: Fri, 15 Jul 2016 11:32:10 +0000
Message-ID: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCCAC33US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 11:32:18 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCCAC33US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hlbiB3ZSBzYXkg4oCcTlAgY29udGFpbmVycyBjYW4gYmUgY3JlYXRlZC9kZWxldGVk4oCdIEkg
Z2VuZXJhbGx5IGludGVycHJldCB0aGF0IHRvIG1lYW4gdGhhdCBpdCBpcyB2YWxpZCB0byBoYXZl
IGFuIG9wZXJhdGlvbj3igJlkZWxldGXigJkgKG9yIGNyZWF0ZSBvciByZW1vdmUgb3IgbWVyZ2Up
IG9uIGFuIE5QIGNvbnRhaW5lciBub2RlIGluIGFuIDxlZGl0LWNvbmZpZz4gcmVxdWVzdCAoZWl0
aGVyIGRpcmVjdGx5IG9yIGluaGVyaXRlZCkuDQoNCkkgZG9u4oCZdCB0aGluayB0aGVyZSBzaG91
bGQgYmUgYW55IHJlYWwgbWVhbmluZyB0byB0aGUgZXhpc3RlbmNlL3ByZXNlbmNlIChvciBub3Qp
IG9mIE5QIGNvbnRhaW5lcnMgaW4gYSBkYXRhc3RvcmUuICAgQnV0IGl0IGRvZXMgc2VlbSB0aGlz
IGlzbuKAmXQgdmVyeSBjbGVhcmx5IGxhaWQgb3V0IGluIHRoZSBSRkNzLg0KDQpUaGV5IGFyZSBw
cmV0dHkgdXNlZnVsIGZvciBkYXRhIG1vZGVsIG9yZ2FuaXphdGlvbiAoYXQgbGVhc3QgZm9yIGh1
bWFucyBsb29raW5nIGF0IGRhdGEvbW9kZWxzKS4NCg0KSmFzb24NCg0KRnJvbTogQW5keSBCaWVy
bWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDE1LCAy
MDE2IDM6MjUNClRvOiBKYW4gTGluZGJsYWQNCkNjOiBYaWFuZyBMaTsgU3Rlcm5lLCBKYXNvbiAo
Tm9raWEgLSBDQSk7IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gV2hhdCBzaG91bGQg
YSBzZXJ2ZXIgcmVzcG9uc2UgYmU/DQoNCkhpLA0KDQpJIGRvIG5vdCBsaWtlIE5QIGNvbnRhaW5l
cnMgYXQgYWxsLg0KVGhleSBoYXZlIHNvIG1hbnkgc3BlY2lhbCBydWxlcy4NCkkgZG9uJ3Qga25v
dyB3aGF0IHByb2JsZW0gaXMgYmVpbmcgc29sdmVkIGJ5IGhhdmluZyB0aGVtIGF0IGFsbC4NCkFs
c28gUkZDIDYyNDEgZGVmaW5lcyBORVRDT05GLCBub3QgWUFORy4NCg0KRXZlbiBpbiB0aGUgWUFO
RyAxLjEgc3BlYywgaXQgc2F5cyBNQVkgZGVsZXRlIGJ1dCBkb2VzIG5vdCBzYXkgTUFZIGNyZWF0
ZSBhbnl3aGVyZS4NCllBTkcgZG9lcyBub3Qgc2F5IE5QIGNvbnRhaW5lcnMgY2Fubm90IGJlIGNy
ZWF0ZWQgb3IgZGVsZXRlZA0KYnkgdGhlIGNsaWVudC4NCg0KDQpBbmR5DQoNCg0KT24gVGh1LCBK
dWwgMTQsIDIwMTYgYXQgMTE6NDYgUE0sIEphbiBMaW5kYmxhZCA8amFubEB0YWlsLWYuY29tPG1h
aWx0bzpqYW5sQHRhaWwtZi5jb20+PiB3cm90ZToNCkluIG9yZGVyIHRvIHJlYWNoIHJvdWdoIGNv
bnNlbnN1cyBvbiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGRlZmF1bHQtb3BlcmF0aW9uPW5v
bmUgc2VxdWVuY2UsIEkgdGhpbmsgd2UgbmVlZCB0byBzdGFydCB3aXRoIGNvbWluZyB0byBhIGNv
bW1vbiB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgTlAgY29udGFpbmVycyBhcmUuIENhbiBOUCBjb250
YWluZXJzIGJlICJjcmVhdGVkIiBhbmQgImRlbGV0ZWQiIGp1c3QgbGlrZSBQIGNvbnRhaW5lcnM/
DQoNCkhlcmUncyBhIHRlc3QgdG8gc2VlIGlmIHRoZXJlIGlzIGFueSBkaWZmZXJlbmNlIGJldHdl
ZW4gdGhlIGJlaGF2aW9yIG9mIHAgYW5kIG5wIGNvbnRhaW5lcnM6DQoNCmxpc3QgdCB7DQogICAg
a2V5IGE7DQogICAgbGVhZiBhIHsgdHlwZSB1aW50MzI7IH0NCiAgICBjb250YWluZXIgbnAgew0K
ICAgICAgICBtdXN0ICIuLi9hID4gMTAiOw0KICAgIH0NCiAgICBjb250YWluZXIgcCB7DQogICAg
ICAgIHByZXNlbmNlICIuLi4iOw0KICAgICAgICBtdXN0ICIuLi9hID4gMjAiOw0KICAgIH0NCn0N
Cg0KVGhlIGNvbmZpZyBpcyBpbml0aWFsbHkgZW1wdHkuIE5vdywgd291bGQgaXQgYmUgcG9zc2li
bGUgdG8NCg0KYSkgY3JlYXRlIGFuIGluc3RhbmNlIHdpdGggYSA9IDUgaWYgdGhlcmUgaXMgbm8g
bWVudGlvbiBvZiBucCBhbmQgcCBpbiB0aGUgZWRpdC1jb25maWc/DQpiKSBjcmVhdGUgYW4gaW5z
dGFuY2Ugd2l0aCBhID0gNSBpZiBucCAoYnV0IG5vdCBwKSBpcyAiY3JlYXRlZCIgaW4gdGhlIGVk
aXQtY29uZmlnPw0KYykgY3JlYXRlIGFuIGluc3RhbmNlIHdpdGggYSA9IDE1IGlmIHRoZXJlIGlz
IG5vIG1lbnRpb24gb2YgbnAgYW5kIHAgaW4gdGhlIGVkaXQtY29uZmlnPw0KZCkgY3JlYXRlIGFu
IGluc3RhbmNlIHdpdGggYSA9IDE1IGlmIHAgaXMgY3JlYXRlZCBpbiB0aGUgZWRpdC1jb25maWc/
DQoNCk15IG93biBhbnN3ZXIgaXMgdGhhdCBvbmx5IG9wZXJhdGlvbiBjIGlzIGFsbG93ZWQuICJj
cmVhdGlvbiIgb2YgYW4gTlAgY29udGFpbmVyIGlzIGlycmVsZXZhbnQsIHdoaWxlIGNyZWF0aW9u
IG9mIGEgUCBjb250YWluZXIgbWFrZXMgYSBkaWZmZXJlbmNlLiBBbiBOUCBjb250YWluZXIgaXMg
c2ltcGx5IGEgc3RydWN0dXJhbCBlbGVtZW50LCBhbmQgZG9lcyBub3QgbmVlZCB0byBiZSAiY3Jl
YXRlZCIgdG8gZXhpc3QsIGJ1dCBlbXB0eSBOUCBjb250YWluZXJzIE1BWSBub3QgYmUgcmVwb3J0
ZWQgc2luY2UgdGhleSBhcmUgbWVhbmluZ2xlc3MgYW55d2F5Lg0KDQpJZiBtdXN0IHN0YXRlbWVu
dHMgaW4gbnAgY29udGFpbmVycyBhcmUgaW4gZWZmZWN0IGV2ZW4gaWYgdGhlIGNsaWVudCBpc24n
dCBleHBsaWNpdGx5ICJjcmVhdGluZyIgb3IgbWVudGlvbmluZyB0aGUgY29udGFpbmVyLCB0aGVu
IEkgZmluZCBpdCBoYXJkIHRvIHVuZGVyc3RhbmQgdGhlIHZpZXdwb2ludCB0aGF0ICJjcmVhdGlv
biIgb2YgTlAgY29udGFpbmVycyBtYWtlcyBhbnkgZGlmZmVyZW5jZS4NCg0KL2phbg0KDQpJIGd1
ZXNzIEkgZG9u4oCZdCByZWFsbHkgc2VlIE5QLWNvbnRhaW5lcnMgYXMg4oCcY29uZmln4oCdLiAg
VGhleSBhcmUganVzdCBzdHJ1Y3R1cmUgYW5kIGZpbHRlcmVkIG91dCB3aGVuIGVtcHR5LiAgSSBk
b27igJl0IHJlYWxseSBzZWUgdGhpcyBhcyB0aGUgc2VydmVyIOKAnGRlbGV0aW5n4oCdIHRob3Nl
IGNvbnRhaW5lcnMuICBJdCBqdXN0IHN1cHByZXNzZXMgdGhlbSBpbiA8Z2V0LWNvbmZpZz4gb3V0
cHV0Lg0KUGxlYXNlIHNob3cgbWUgdGhlIFJGQyB0ZXh0IHRoYXQgc2F5cyB0aGUgc2VydmVyIGNh
biBmaWx0ZXIgb3V0IE5QIGNvbnRhaW5lcnMuDQpBbGwgY29uZmlnPXRydWUgZGF0YSBub2RlcyBh
cmUgY29uZmlnLg0KDQpJbiBhIHZlcnkgdGVjaG5pY2FsIHNlbnNlLCBJIHN1cHBvc2UgdGhlIGFi
b3ZlIHN0YXRlbWVudCBpcyBjb3JyZWN0LiBBbiBOUCBjb250YWluZXIgaXMgb2YgY291cnNlIGNv
bmZpZyB0cnVlIGlmIGl0IHNpdHMgaW4gdGhlIGNvbmZpZyB0cnVlIHBhcnQgb2YgdGhlIHRyZWUu
IEF0IHRoZSBzYW1lIHRpbWUgSSBhZ3JlZSB3aXRoIEphbnNvbidzIHZpZXcgdGhhdCBOUCBjb250
YWluZXJzIGFyZSBqdXN0IHN0cnVjdHVyZSwgc28gdGhlIHF1ZXN0aW9uIG9mIHRoZWlyICJleGlz
dGVuY2UiIGlzIG1vb3QuDQoNCkhlcmUncyB3aGF0IFJGQyA2MDIwLCBzZWMgNy41IHNheXMgb24g
dGhlIHRvcGljOg0KDQoNCiAgIFlBTkcgc3VwcG9ydHMgdHdvIHN0eWxlcyBvZiBjb250YWluZXJz
LCB0aG9zZSB0aGF0IGV4aXN0IG9ubHkgZm9yDQoNCiAgIG9yZ2FuaXppbmcgdGhlIGhpZXJhcmNo
eSBvZiBkYXRhIG5vZGVzLCBhbmQgdGhvc2Ugd2hvc2UgcHJlc2VuY2UgaW4NCg0KICAgdGhlIGNv
bmZpZ3VyYXRpb24gaGFzIGFuIGV4cGxpY2l0IG1lYW5pbmcuDQoNClNvIE5QIGNvbnRhaW5lcnMg
ImV4aXN0IG9ubHkgZm9yIG9yZ2FuaXppbmcgdGhlIGhpZXJhcmNoeSIgd2hpbGUgYSBQIGNvbnRh
aW5lciAiaGFzIGFuIGV4cGxpY2l0IG1lYW5pbmciLiBJIGd1ZXNzIHRoaXMgaW1wbGllcyBOUCBj
b250YWluZXJzIGhhdmluZyBubyBtZWFuaW5nLiBGdXJ0aGVyIGRvd24gaW4gNy41LjEsIHJlIFAg
Y29udGFpbmVycywgaXQgaXMgbm90ZWQgdGhhdDoNCg0KDQogICBJbiB0aGUgc2Vjb25kIHN0eWxl
LCB0aGUgcHJlc2VuY2Ugb2YgdGhlIGNvbnRhaW5lciBpdHNlbGYgaXMNCg0KICAgY29uZmlndXJh
dGlvbiBkYXRhLCByZXByZXNlbnRpbmcgYSBzaW5nbGUgYml0IG9mIGNvbmZpZ3VyYXRpb24gZGF0
YS4NCg0KICAgVGhlIGNvbnRhaW5lciBhY3RzIGFzIGJvdGggYSBjb25maWd1cmF0aW9uIGtub2Ig
YW5kIGEgbWVhbnMgb2YNCg0KICAgb3JnYW5pemluZyByZWxhdGVkIGNvbmZpZ3VyYXRpb24uICBU
aGVzZSBjb250YWluZXJzIGFyZSBleHBsaWNpdGx5DQoNCiAgIGNyZWF0ZWQgYW5kIGRlbGV0ZWQu
DQoNCkJhc2VkIG9uIHRoZXNlIGZyYWdtZW50cywgSSBjb25jbHVkZSB0aGF0IE5QIGNvbnRhaW5l
cnMgaGF2ZSB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24uIFRoaXMgbWVhbnMgdGhlIGV4aXN0ZW5j
ZS9hYnNlbmNlIG9mIGFuIE5QIGNvbnRhaW5lciBjYW5ub3QgYmUga25vd24vc3RvcmVkL3JlbWVt
YmVyZWQgZXZlbiBpbnRlcm5hbGx5IGJ5IGEgY29uZm9ybWluZyBzeXN0ZW0uIFRoZSBleGlzdGVu
Y2UvYWJzZW5jZSBvZiBhbiBOUCBjb250YWluZXIgaXMgYSBtb290IHF1ZXN0aW9uLiBJdCdzIGEg
Yml0IGxpa2UgYXNraW5nIGZvciB0aGUgdmFsdWUgb2YgYSB2b2lkIGZ1bmN0aW9uLiBJdCdzIHRo
ZXJlLCBpdCBoYXMgYSBuYW1lLCBidXQgbm8gdmFsdWUuDQoNCkltcGxlbWVudGF0aW9ucyB0aGF0
IHJlY2VpdmUgYSA8Z2V0PiBvciA8Z2V0LWNvbmZpZz4gcmVxdWVzdCB0aGF0IGNvbnRhaW5zIGFu
IE5QIGNvbnRhaW5lciB3aWxsIGhhdmUgdG8gZGVjaWRlIHdoZXRoZXIgdG8gaW5jbHVkZSB0aGUg
TlAgY29udGFpbmVyIGluIHRoZSByZXNwb25zZSBvciBub3QuIFNpbmNlIHRoZSBleGlzdGVuY2Ug
b2YgdGhlIE5QIGNvbnRhaW5lciBjYW5ub3QgYmUgcmVhZCBmcm9tIGEgZGF0YWJhc2UvZXRjIChp
dCBoYXMgemVybyBiaXRzIG9mIGluZm9ybWF0aW9uKSwgdGhlIGltcGxlbWVudGF0aW9uIHdpbGwg
aGF2ZSB0byB1c2Ugc29tZSBvdGhlciB3YXkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdG8gaW5jbHVk
ZSBpdCBvciBub3QuDQoNCkluIG9yZGVyIHRvIG1ha2UgdGhlIGxpZmUgZWFzaWVyIGZvciBpbXBs
ZW1lbnRvcnMsIHRoZSBmb2xsb3dpbmcgTUFZIHdhcyBpbnRyb2R1Y2VkIGluIHNlYyA3LjUuNzoN
Cg0KDQogICBBIE5FVENPTkYgc2VydmVyIHRoYXQgcmVwbGllcyB0byBhIDxnZXQ+IG9yIDxnZXQt
Y29uZmlnPiByZXF1ZXN0IE1BWQ0KDQogICBjaG9vc2Ugbm90IHRvIHNlbmQgYSBjb250YWluZXIg
ZWxlbWVudCBpZiB0aGUgY29udGFpbmVyIG5vZGUgZG9lcyBub3QNCg0KICAgaGF2ZSB0aGUgInBy
ZXNlbmNlIiBzdGF0ZW1lbnQgYW5kIG5vIGNoaWxkIG5vZGVzIGV4aXN0Lg0KDQpTbyB0aGUgTlAg
Y29udGFpbmVyIGhhcyB0byBiZSBpbmNsdWRlZCBpZiBpdCBoYXMgY2hpbGRyZW4sIG9yIGVsc2Ug
dGhlIHN0cnVjdHVyYWwgZnVuY3Rpb24gb2YgdGhlIGNvbnRhaW5lciB3b3VsZCBiZSBsb3N0LiBJ
ZiB0aGUgTlAgY29udGFpbmVyIGlzIGVtcHR5LCBpdCBtYXkgb3IgbWF5IG5vdCBiZSBzZW50LiBT
aW5jZSBhbiBOUCBjb250YWluZXIgaGFzIHplcm8gYml0cyBvZiBpbmZvcm1hdGlvbiwgdGhpcyBk
ZWNpc2lvbiB3b3VsZCBub3QgYmUgYmFzZWQgb24gd2hldGhlciBpdCBoYXMgYmVlbiBwcmV2aW91
c2x5ICJjcmVhdGVkIiBvciAiZGVsZXRlZCIsIGJ1dCBvbiBpbXBsZW1lbnRhdGlvbiBjb25zaWRl
cmF0aW9ucy4gT25lIHBvc3NpYmxlIGFwcHJvYWNoIGlzIHRvIGFsd2F5cyBpbmNsdWRlIGl0LCBh
bm90aGVyIHRvIGFjdHVhbGx5IGNoZWNrIGlmIHRoZXJlIGFyZSBhbnkgY2hpbGRyZW4sIGFuZCBv
bmx5IHJldHVybiBpdCB0aGVuLg0KDQpFaXRoZXIgd2F5LCBOUCBjb250YWluZXJzIGFsb25lIGhh
dmUgbm8gbWVhbmluZy9pbmZvcm1hdGlvbiwgdGhleSBhcmUgb25seSB0aGVyZSBmb3Igc3RydWN0
dXJlLg0KDQoNCkEgZmFsc2UgbXVzdC1zdG10IGluIGFuIE5QLWNvbnRhaW5lciBpcyBzdGlsbCBh
biBlcnJvci4NCg0KQ2VydGFpbmx5LiBNdXN0IHN0YXRlbWVudHMgb24gYW4gTlAgY29udGFpbmVy
IGFyZSBhbHdheXMgZXZhbHVhdGVkLCBldmVuIGlmIHRoZSBjb250YWluZXIgaGFzbid0IGJlZW4g
ImNyZWF0ZWQiIG9yIG1lbnRpb25lZCBieSBhIGNsaWVudCwgYW5kIGV2ZW4gaWYgaXQgaGFzIG5v
IGNoaWxkIGVsZW1lbnRzLg0KDQoNCkFzIExhZGEgaGFzIHBvaW50ZWQgb3V0IG1hbnkgdGltZXMs
IHRoZSB0ZXh0IGFib3V0DQpOUCBjb250YWluZXJzIG5vdCBiZWluZyBwYXJ0IG9mIHRoZSBkYXRh
IG1vZGVsIGlzIGp1c3Qgd3JvbmcuDQoNCkkgdGhpbmsgdGhlIGxlbmd0aCBvZiB0aGlzIGRpc2N1
c3Npb24gaW1wbGllcyB3ZSBzaG91bGQgaW5jbHVkZSB0aGlzIHRvcGljIGluIHRoZSB1cGNvbWlu
ZyBZQU5HIEZBUS4NClRoZSBzZXJ2ZXIgc2hvdWxkIG5vdCBlcnJvciBpbiB0aGUgY2FzZXMgTWFo
ZXNoICYgRWluYXIgc2hvdyAtPiB0aGUgcHJlc2VuY2UvZXhpc3RlbmNlIG9mIE5QLWNvbnRhaW5l
cnMgc2hvdWxkbuKAmXQgcmVhbGx5IGFmZmVjdCBiZWhhdmlvciAoc2luY2UgdGhleSBhcmVu4oCZ
dCByZWFsbHkgY29uZmlnKS4NCkkgYWdyZWUgd2l0aCB0aGUgYWJvdmUuDQoNCkJ1dCBJ4oCZbSBu
b3QgcG9zaXRpdmUgd2hhdCB5b3UgbWVhbiBieSDigJxtYW5hZ2VyIG5lZWRzIHRvIGd1YXJk4oCd
LiAgRG8geW91IGFncmVlIHRoYXQgdGhlIHNlcnZlciBzaG91bGQgbm90IGVycm9yIGluIHRob3Nl
IGNhc2VzIGJlbG93ID8NClRoZSBZQU5HIHRleHQgc2F5cyBhIHNlcnZlciBNQVkgZGVsZXRlIGFu
IGVtcHR5IE5QIGNvbnRhaW5lci4NClVzaW5nIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgaW1wbGll
cyB0aGF0IHRoZSBjbGllbnQgaXMgc3VyZSB0aGUgbm9kZXMgZm9yIG9wZXJhdGlvbj1ub25lDQph
Y3R1YWxseSBleGlzdC4gIEJlY2F1c2Ugb2YgdGhpcyBZQU5HIGRldGFpbCwgdGhlIGNsaWVudCBj
YW5ub3QgYmUgc3VyZSBzbyB1c2luZw0KZGVmYXVsdC1vcGVyYXRpb249bm9uZSBtYXkgbm90IHdv
cmsuDQoNCkkgZGlzYWdyZWUgd2l0aCB0aGlzIGNvbmNsdXNpb24uIEV2ZW4gdXNpbmcgZGVmYXVs
dC1vcGVyYXRpb249bm9uZSB0aGUgdHJhbnNhY3Rpb25zIG11c3QgYmUgZ3VhcmFudGVlZCB0byB3
b3JrIGJ5IGEgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbi4gTlAgY29udGFpbmVycyBjYW5ub3Qg
YmUgY3JlYXRlZC9kZWxldGVkIGluIGEgZGVlcGVyIHNlbnNlIG9mIHRoZSB3b3JkIHNpbmNlIHRo
ZXkgaGF2ZSB6ZXJvIGluZm9ybWF0aW9uIGNvbnRlbnQuIFRoZXkgY2FuIG9ubHkgYmUgcmVmZXJy
ZWQgdG8uIEFueSBtdXN0IHN0YXRlbWVudHMgd2l0aGluIHRoZSBjb250YWluZXIgbXVzdCBiZSBl
dmFsdWF0ZWQgcmVnYXJkbGVzcyBvZiB0aGUgY2xpZW50IGV2ZXIgbWVudGlvbmluZyB0aGUgY29u
dGFpbmVyLg0KDQoNCg0KSSBkbyBub3QgYWdyZWUgdGhhdCBkZWZhdWx0LW9wZXJhdGlvbj1ub25l
IGRvZXMgbm90IGFwcGx5IHRvIE5QIGNvbnRhaW5lcnMuDQoNClRoaXMgaXMgd2h5IGl0IHdhcyBz
dWNoIGEgYmFkIGRlY2lzaW9uIHRvIHNwcmVhZCBsaXR0bGUgcGllY2VzIG9mIE5FVENPTkYNCmFs
bCBvdmVyIHRoZSBZQU5HIFJGQy4gUkZDIDYyNDEgZGVmaW5lcyB0aGUgJ2RlZmF1bHQtb3BlcmF0
aW9uJyBsZWFmDQphbmQgaXQgZG9lcyBub3Qgc2F5IGFueXRoaW5nIGFib3V0IHNwZWNpYWwgdHJl
YXRtZW50IGZvciBOUCBjb250YWluZXJzLg0KDQoNCiAgIG5vbmU6ICBUaGUgdGFyZ2V0IGRhdGFz
dG9yZSBpcyB1bmFmZmVjdGVkIGJ5IHRoZSBjb25maWd1cmF0aW9uDQoNCiAgICAgICAgICAgIGlu
IHRoZSA8Y29uZmlnPiBwYXJhbWV0ZXIsIHVubGVzcyBhbmQgdW50aWwgdGhlIGluY29taW5nDQoN
CiAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gZGF0YSB1c2VzIHRoZSAib3BlcmF0aW9uIiBhdHRy
aWJ1dGUgdG8gcmVxdWVzdA0KDQogICAgICAgICAgICBhIGRpZmZlcmVudCBvcGVyYXRpb24uICBJ
ZiB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUgPGNvbmZpZz4NCg0KICAgICAgICAgICAgcGFyYW1l
dGVyIGNvbnRhaW5zIGRhdGEgZm9yIHdoaWNoIHRoZXJlIGlzIG5vdCBhDQoNCiAgICAgICAgICAg
IGNvcnJlc3BvbmRpbmcgbGV2ZWwgaW4gdGhlIHRhcmdldCBkYXRhc3RvcmUsIGFuIDxycGMtZXJy
b3I+DQoNCiAgICAgICAgICAgIGlzIHJldHVybmVkIHdpdGggYW4gPGVycm9yLXRhZz4gdmFsdWUg
b2YgZGF0YS1taXNzaW5nLg0KDQogICAgICAgICAgICBVc2luZyAibm9uZSIgYWxsb3dzIG9wZXJh
dGlvbnMgbGlrZSAiZGVsZXRlIiB0byBhdm9pZA0KDQogICAgICAgICAgICB1bmludGVudGlvbmFs
bHkgY3JlYXRpbmcgdGhlIHBhcmVudCBoaWVyYXJjaHkgb2YgdGhlIGVsZW1lbnQNCg0KICAgICAg
ICAgICAgdG8gYmUgZGVsZXRlZC4NCg0KDQovamFuDQoNCg0KQW5keQ0KDQoNCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCCAC33US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0
IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6
MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUaW1lc05l
d1JvbWFuUFNNVDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg
Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1h
dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi
Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X
aGVuIHdlIHNheSDigJxOUCBjb250YWluZXJzIGNhbiBiZSBjcmVhdGVkL2RlbGV0ZWTigJ0gSSBn
ZW5lcmFsbHkgaW50ZXJwcmV0IHRoYXQgdG8gbWVhbiB0aGF0IGl0IGlzIHZhbGlkIHRvIGhhdmUg
YW4gb3BlcmF0aW9uPeKAmWRlbGV0ZeKAmSAob3IgY3JlYXRlIG9yIHJlbW92ZSBvcg0KIG1lcmdl
KSBvbiBhbiBOUCBjb250YWluZXIgbm9kZSBpbiBhbiAmbHQ7ZWRpdC1jb25maWcmZ3Q7IHJlcXVl
c3QgKGVpdGhlciBkaXJlY3RseSBvciBpbmhlcml0ZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRo
aW5rIHRoZXJlIHNob3VsZCBiZSBhbnkgcmVhbCBtZWFuaW5nIHRvIHRoZSBleGlzdGVuY2UvcHJl
c2VuY2UgKG9yIG5vdCkgb2YgTlAgY29udGFpbmVycyBpbiBhIGRhdGFzdG9yZS4mbmJzcDsmbmJz
cDsgQnV0IGl0IGRvZXMgc2VlbSB0aGlzIGlzbuKAmXQgdmVyeSBjbGVhcmx5DQogbGFpZCBvdXQg
aW4gdGhlIFJGQ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGV5IGFyZSBwcmV0dHkgdXNlZnVsIGZvciBkYXRhIG1v
ZGVsIG9yZ2FuaXphdGlvbiAoYXQgbGVhc3QgZm9yIGh1bWFucyBsb29raW5nIGF0IGRhdGEvbW9k
ZWxzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkphc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4gW21haWx0bzph
bmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE1LCAy
MDE2IDM6MjU8YnI+DQo8Yj5Ubzo8L2I+IEphbiBMaW5kYmxhZDxicj4NCjxiPkNjOjwvYj4gWGlh
bmcgTGk7IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpOyBOZXRjb25mPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbTmV0Y29uZl0gV2hhdCBzaG91bGQgYSBzZXJ2ZXIgcmVzcG9uc2UgYmU/PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IGxpa2UgTlAgY29u
dGFpbmVycyBhdCBhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5UaGV5IGhhdmUgc28gbWFueSBzcGVjaWFsIHJ1bGVzLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBrbm93IHdoYXQg
cHJvYmxlbSBpcyBiZWluZyBzb2x2ZWQgYnkgaGF2aW5nIHRoZW0gYXQgYWxsLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBSRkMgNjI0MSBk
ZWZpbmVzIE5FVENPTkYsIG5vdCBZQU5HLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGluIHRoZSBZQU5HIDEuMSBzcGVjLCBpdCBzYXlz
IE1BWSBkZWxldGUgYnV0IGRvZXMgbm90IHNheSBNQVkgY3JlYXRlIGFueXdoZXJlLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WUFORyBkb2VzIG5v
dCBzYXkgTlAgY29udGFpbmVycyBjYW5ub3QgYmUgY3JlYXRlZCBvciBkZWxldGVkPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ieSB0aGUgY2xpZW50
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCAxMTo0NiBQTSwgSmFuIExpbmRibGFkICZsdDs8
YSBocmVmPSJtYWlsdG86amFubEB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFubEB0YWls
LWYuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SW4gb3JkZXIgdG8gcmVhY2ggcm91Z2ggY29uc2Vuc3VzIG9uIHRoZSBpbnRlcnBy
ZXRhdGlvbiBvZiB0aGUgZGVmYXVsdC1vcGVyYXRpb249bm9uZSBzZXF1ZW5jZSwgSSB0aGluayB3
ZSBuZWVkIHRvIHN0YXJ0IHdpdGggY29taW5nIHRvIGEgY29tbW9uIHVuZGVyc3RhbmRpbmcgb2Yg
d2hhdCBOUCBjb250YWluZXJzIGFyZS4gQ2FuIE5QIGNvbnRhaW5lcnMgYmUgJnF1b3Q7Y3JlYXRl
ZCZxdW90OyBhbmQgJnF1b3Q7ZGVsZXRlZCZxdW90OyBqdXN0DQogbGlrZSBQIGNvbnRhaW5lcnM/
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlJ3MgYSB0
ZXN0IHRvIHNlZSBpZiB0aGVyZSBpcyBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBiZWhhdmlv
ciBvZiBwIGFuZCBucCBjb250YWluZXJzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5saXN0IHQgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBrZXkgYTs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg
bGVhZiBhIHsgdHlwZSB1aW50MzI7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgY29udGFpbmVyIG5wIHs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBtdXN0ICZxdW90Oy4uL2EgJmd0OyAxMCZxdW90Ozs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgfTxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
ICZuYnNwOyBjb250YWluZXIgcCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJlc2VuY2UgJnF1
b3Q7Li4uJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG11c3QgJnF1b3Q7Li4vYSAmZ3Q7
IDIwJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoZSBjb25maWcgaXMgaW5pdGlhbGx5IGVtcHR5LiBOb3csIHdvdWxk
IGl0IGJlIHBvc3NpYmxlIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPmEpIGNyZWF0ZSBhbiBpbnN0YW5jZSB3aXRoIGEgPSA1IGlmIHRoZXJl
IGlzIG5vIG1lbnRpb24gb2YgbnAgYW5kIHAgaW4gdGhlIGVkaXQtY29uZmlnPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YikgY3JlYXRlIGFuIGlu
c3RhbmNlIHdpdGggYSA9IDUgaWYgbnAgKGJ1dCBub3QgcCkgaXMgJnF1b3Q7Y3JlYXRlZCZxdW90
OyBpbiB0aGUgZWRpdC1jb25maWc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5jKSBjcmVhdGUgYW4gaW5zdGFuY2Ugd2l0aCBhID0gMTUgaWYgdGhl
cmUgaXMgbm8gbWVudGlvbiBvZiBucCBhbmQgcCBpbiB0aGUgZWRpdC1jb25maWc/PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kKSBjcmVhdGUgYW4g
aW5zdGFuY2Ugd2l0aCBhID0gMTUgaWYgcCBpcyBjcmVhdGVkIGluIHRoZSBlZGl0LWNvbmZpZz88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+TXkgb3duIGFuc3dlciBpcyB0aGF0IG9ubHkgb3BlcmF0aW9uIGMgaXMgYWxs
b3dlZC4gJnF1b3Q7Y3JlYXRpb24mcXVvdDsgb2YgYW4gTlAgY29udGFpbmVyIGlzIGlycmVsZXZh
bnQsIHdoaWxlIGNyZWF0aW9uIG9mIGEgUCBjb250YWluZXIgbWFrZXMgYSBkaWZmZXJlbmNlLiBB
biBOUCBjb250YWluZXIgaXMgc2ltcGx5IGEgc3RydWN0dXJhbCBlbGVtZW50LCBhbmQgZG9lcyBu
b3QgbmVlZCB0byBiZSAmcXVvdDtjcmVhdGVkJnF1b3Q7IHRvIGV4aXN0LA0KIGJ1dCBlbXB0eSBO
UCBjb250YWluZXJzIE1BWSBub3QgYmUgcmVwb3J0ZWQgc2luY2UgdGhleSBhcmUgbWVhbmluZ2xl
c3MgYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JZiBtdXN0IHN0YXRlbWVudHMgaW4gbnAgY29udGFpbmVycyBhcmUgaW4gZWZmZWN0
IGV2ZW4gaWYgdGhlIGNsaWVudCBpc24ndCBleHBsaWNpdGx5ICZxdW90O2NyZWF0aW5nJnF1b3Q7
IG9yIG1lbnRpb25pbmcgdGhlIGNvbnRhaW5lciwgdGhlbiBJIGZpbmQgaXQgaGFyZCB0byB1bmRl
cnN0YW5kIHRoZSB2aWV3cG9pbnQgdGhhdCAmcXVvdDtjcmVhdGlvbiZxdW90OyBvZiBOUCBjb250
YWluZXJzIG1ha2VzIGFueSBkaWZmZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vamFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K
PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SSBndWVzcyBJIGRvbuKAmXQgcmVhbGx5IHNlZSBOUC1jb250YWluZXJzIGFzIOKA
nGNvbmZpZ+KAnS4mbmJzcDsgVGhleSBhcmUganVzdCBzdHJ1Y3R1cmUgYW5kIGZpbHRlcmVkIG91
dCB3aGVuDQogZW1wdHkuJm5ic3A7IEkgZG9u4oCZdCByZWFsbHkgc2VlIHRoaXMgYXMgdGhlIHNl
cnZlciDigJxkZWxldGluZ+KAnSB0aG9zZSBjb250YWluZXJzLiZuYnNwOyBJdCBqdXN0IHN1cHBy
ZXNzZXMgdGhlbSBpbiAmbHQ7Z2V0LWNvbmZpZyZndDsgb3V0cHV0LiAmbmJzcDsmbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6VGltZXNOZXdSb21hblBTTVQiPlBsZWFzZSBzaG93IG1lIHRoZSBSRkMgdGV4dCB0aGF0
IHNheXMgdGhlIHNlcnZlciBjYW4gZmlsdGVyIG91dCBOUCBjb250YWluZXJzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPkFsbCBj
b25maWc9dHJ1ZSBkYXRhIG5vZGVzIGFyZSBjb25maWcuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpUaW1lc05ld1JvbWFuUFNNVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+SW4gYSB2ZXJ5IHRlY2huaWNhbCBzZW5z
ZSwgSSBzdXBwb3NlIHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgY29ycmVjdC4gQW4gTlAgY29udGFp
bmVyIGlzIG9mIGNvdXJzZSBjb25maWcgdHJ1ZSBpZiBpdCBzaXRzIGluIHRoZSBjb25maWcgdHJ1
ZSBwYXJ0IG9mIHRoZSB0cmVlLiBBdCB0aGUgc2FtZSB0aW1lIEkNCiBhZ3JlZSB3aXRoIEphbnNv
bidzIHZpZXcgdGhhdCBOUCBjb250YWluZXJzIGFyZSBqdXN0IHN0cnVjdHVyZSwgc28gdGhlIHF1
ZXN0aW9uIG9mIHRoZWlyICZxdW90O2V4aXN0ZW5jZSZxdW90OyBpcyBtb290LiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNO
ZXdSb21hblBTTVQiPkhlcmUncyB3aGF0IFJGQyA2MDIwLCBzZWMgNy41IHNheXMgb24gdGhlIHRv
cGljOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdS
b21hblBTTVQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdCI+Jm5ic3A7Jm5ic3A7IFlBTkcgc3VwcG9y
dHMgdHdvIHN0eWxlcyBvZiBjb250YWluZXJzLCB0aG9zZSB0aGF0IGV4aXN0IG9ubHkgZm9yPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQi
PiZuYnNwOyZuYnNwOyBvcmdhbml6aW5nIHRoZSBoaWVyYXJjaHkgb2YgZGF0YSBub2RlcywgYW5k
IHRob3NlIHdob3NlIHByZXNlbmNlIGluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPiZuYnNwOyZuYnNwOyB0aGUgY29uZmlndXJhdGlv
biBoYXMgYW4gZXhwbGljaXQgbWVhbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01UIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPlNvIE5QIGNvbnRh
aW5lcnMgJnF1b3Q7ZXhpc3Qgb25seSBmb3Igb3JnYW5pemluZyB0aGUgaGllcmFyY2h5JnF1b3Q7
IHdoaWxlIGEgUCBjb250YWluZXIgJnF1b3Q7aGFzIGFuIGV4cGxpY2l0IG1lYW5pbmcmcXVvdDsu
IEkgZ3Vlc3MgdGhpcyBpbXBsaWVzIE5QIGNvbnRhaW5lcnMgaGF2aW5nIG5vIG1lYW5pbmcuIEZ1
cnRoZXIgZG93biBpbg0KIDcuNS4xLCByZSBQIGNvbnRhaW5lcnMsIGl0IGlzIG5vdGVkIHRoYXQ6
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFu
UFNNVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0Ij4mbmJzcDsmbmJzcDsgSW4gdGhlIHNlY29uZCBz
dHlsZSwgdGhlIHByZXNlbmNlIG9mIHRoZSBjb250YWluZXIgaXRzZWxmIGlzPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPiZuYnNwOyZu
YnNwOyBjb25maWd1cmF0aW9uIGRhdGEsIHJlcHJlc2VudGluZyBhIHNpbmdsZSBiaXQgb2YgY29u
ZmlndXJhdGlvbiBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdCI+Jm5ic3A7Jm5ic3A7IFRoZSBjb250YWluZXIgYWN0
cyBhcyBib3RoIGEgY29uZmlndXJhdGlvbiBrbm9iIGFuZCBhIG1lYW5zIG9mPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPiZuYnNwOyZu
YnNwOyBvcmdhbml6aW5nIHJlbGF0ZWQgY29uZmlndXJhdGlvbi4mbmJzcDsgVGhlc2UgY29udGFp
bmVycyBhcmUgZXhwbGljaXRseTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguNXB0Ij4mbmJzcDsmbmJzcDsgY3JlYXRlZCBhbmQgZGVsZXRlZC48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21h
blBTTVQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+QmFzZWQgb24gdGhlc2UgZnJhZ21lbnRzLCBJIGNv
bmNsdWRlIHRoYXQgTlAgY29udGFpbmVycyBoYXZlIHplcm8gYml0cyBvZiBpbmZvcm1hdGlvbi4g
VGhpcyBtZWFucyB0aGUgZXhpc3RlbmNlL2Fic2VuY2Ugb2YgYW4gTlAgY29udGFpbmVyIGNhbm5v
dCBiZSBrbm93bi9zdG9yZWQvcmVtZW1iZXJlZCBldmVuDQogaW50ZXJuYWxseSBieSBhIGNvbmZv
cm1pbmcgc3lzdGVtLiBUaGUgZXhpc3RlbmNlL2Fic2VuY2Ugb2YgYW4gTlAgY29udGFpbmVyIGlz
IGEgbW9vdCBxdWVzdGlvbi4gSXQncyBhIGJpdCBsaWtlIGFza2luZyBmb3IgdGhlIHZhbHVlIG9m
IGEgdm9pZCBmdW5jdGlvbi4gSXQncyB0aGVyZSwgaXQgaGFzIGEgbmFtZSwgYnV0IG5vIHZhbHVl
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21h
blBTTVQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
VGltZXNOZXdSb21hblBTTVQiPkltcGxlbWVudGF0aW9ucyB0aGF0IHJlY2VpdmUgYSAmbHQ7Z2V0
Jmd0OyBvciAmbHQ7Z2V0LWNvbmZpZyZndDsgcmVxdWVzdCB0aGF0IGNvbnRhaW5zIGFuIE5QIGNv
bnRhaW5lciB3aWxsIGhhdmUgdG8gZGVjaWRlIHdoZXRoZXIgdG8gaW5jbHVkZSB0aGUgTlAgY29u
dGFpbmVyIGluIHRoZSByZXNwb25zZSBvciBub3QuIFNpbmNlDQogdGhlIGV4aXN0ZW5jZSBvZiB0
aGUgTlAgY29udGFpbmVyIGNhbm5vdCBiZSByZWFkIGZyb20gYSBkYXRhYmFzZS9ldGMgKGl0IGhh
cyB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24pLCB0aGUgaW1wbGVtZW50YXRpb24gd2lsbCBoYXZl
IHRvIHVzZSBzb21lIG90aGVyIHdheSB0byBkZXRlcm1pbmUgd2hldGhlciB0byBpbmNsdWRlIGl0
IG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVz
TmV3Um9tYW5QU01UIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01UIj5JbiBvcmRlciB0byBtYWtlIHRoZSBsaWZlIGVhc2ll
ciBmb3IgaW1wbGVtZW50b3JzLCB0aGUgZm9sbG93aW5nIE1BWSB3YXMgaW50cm9kdWNlZCBpbiBz
ZWMgNy41Ljc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1l
c05ld1JvbWFuUFNNVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0Ij4mbmJzcDsmbmJzcDsgQSBORVRD
T05GIHNlcnZlciB0aGF0IHJlcGxpZXMgdG8gYSAmbHQ7Z2V0Jmd0OyBvciAmbHQ7Z2V0LWNvbmZp
ZyZndDsgcmVxdWVzdCBNQVk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjVwdCI+Jm5ic3A7Jm5ic3A7IGNob29zZSBub3QgdG8gc2VuZCBhIGNv
bnRhaW5lciBlbGVtZW50IGlmIHRoZSBjb250YWluZXIgbm9kZSBkb2VzIG5vdDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0Ij4mbmJzcDsm
bmJzcDsgaGF2ZSB0aGUgJnF1b3Q7cHJlc2VuY2UmcXVvdDsgc3RhdGVtZW50IGFuZCBubyBjaGls
ZCBub2RlcyBleGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVz
TmV3Um9tYW5QU01UIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPlNvIHRoZSBOUCBjb250YWluZXIgaGFz
IHRvIGJlIGluY2x1ZGVkIGlmIGl0IGhhcyBjaGlsZHJlbiwgb3IgZWxzZSB0aGUgc3RydWN0dXJh
bCBmdW5jdGlvbiBvZiB0aGUgY29udGFpbmVyIHdvdWxkIGJlIGxvc3QuIElmIHRoZSBOUCBjb250
YWluZXIgaXMgZW1wdHksIGl0IG1heSBvciBtYXkgbm90IGJlIHNlbnQuDQogU2luY2UgYW4gTlAg
Y29udGFpbmVyIGhhcyB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24sIHRoaXMgZGVjaXNpb24gd291
bGQgbm90IGJlIGJhc2VkIG9uIHdoZXRoZXIgaXQgaGFzIGJlZW4gcHJldmlvdXNseSAmcXVvdDtj
cmVhdGVkJnF1b3Q7IG9yICZxdW90O2RlbGV0ZWQmcXVvdDssIGJ1dCBvbiBpbXBsZW1lbnRhdGlv
biBjb25zaWRlcmF0aW9ucy4gT25lIHBvc3NpYmxlIGFwcHJvYWNoIGlzIHRvIGFsd2F5cyBpbmNs
dWRlIGl0LCBhbm90aGVyIHRvIGFjdHVhbGx5IGNoZWNrIGlmDQogdGhlcmUgYXJlIGFueSBjaGls
ZHJlbiwgYW5kIG9ubHkgcmV0dXJuIGl0IHRoZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+RWl0aGVyIHdh
eSwgTlAgY29udGFpbmVycyBhbG9uZSBoYXZlIG5vIG1lYW5pbmcvaW5mb3JtYXRpb24sIHRoZXkg
YXJlIG9ubHkgdGhlcmUgZm9yIHN0cnVjdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01U
Ij5BIGZhbHNlIG11c3Qtc3RtdCBpbiBhbiBOUC1jb250YWluZXIgaXMgc3RpbGwgYW4gZXJyb3Iu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+Q2VydGFpbmx5LiBNdXN0
IHN0YXRlbWVudHMgb24gYW4gTlAgY29udGFpbmVyIGFyZSBhbHdheXMgZXZhbHVhdGVkLCBldmVu
IGlmIHRoZSBjb250YWluZXIgaGFzbid0IGJlZW4gJnF1b3Q7Y3JlYXRlZCZxdW90OyBvciBtZW50
aW9uZWQgYnkgYSBjbGllbnQsIGFuZCBldmVuIGlmIGl0IGhhcyBubyBjaGlsZCBlbGVtZW50cy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPjxi
cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01UIj5BcyBMYWRhIGhhcyBwb2ludGVkIG91dCBtYW55
IHRpbWVzLCB0aGUgdGV4dCBhYm91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPk5QIGNvbnRhaW5lcnMgbm90IGJlaW5nIHBhcnQg
b2YgdGhlIGRhdGEgbW9kZWwgaXMganVzdCB3cm9uZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW5Q
U01UIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRp
bWVzTmV3Um9tYW5QU01UIj5JIHRoaW5rIHRoZSBsZW5ndGggb2YgdGhpcyBkaXNjdXNzaW9uIGlt
cGxpZXMgd2Ugc2hvdWxkIGluY2x1ZGUgdGhpcyB0b3BpYyBpbiB0aGUgdXBjb21pbmcgWUFORyBG
QVEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBzZXJ2ZXIgc2hvdWxkIG5v
dCBlcnJvciBpbiB0aGUgY2FzZXMgTWFoZXNoICZhbXA7IEVpbmFyIHNob3cgLSZndDsgdGhlIHBy
ZXNlbmNlL2V4aXN0ZW5jZSBvZiBOUC1jb250YWluZXJzDQogc2hvdWxkbuKAmXQgcmVhbGx5IGFm
ZmVjdCBiZWhhdmlvciAoc2luY2UgdGhleSBhcmVu4oCZdCByZWFsbHkgY29uZmlnKS4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNN
VCI+SSBhZ3JlZSB3aXRoIHRoZSBhYm92ZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5CdXQgSeKAmW0gbm90IHBvc2l0aXZlIHdoYXQgeW91IG1lYW4gYnkg4oCcbWFuYWdlciBu
ZWVkcyB0byBndWFyZOKAnS4mbmJzcDsgRG8geW91IGFncmVlIHRoYXQgdGhlIHNlcnZlciBzaG91
bGQNCiBub3QgZXJyb3IgaW4gdGhvc2UgY2FzZXMgYmVsb3cgPzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1Jv
bWFuUFNNVCI+VGhlIFlBTkcgdGV4dCBzYXlzIGEgc2VydmVyIE1BWSBkZWxldGUgYW4gZW1wdHkg
TlAgY29udGFpbmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
VGltZXNOZXdSb21hblBTTVQiPlVzaW5nIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgaW1wbGllcyB0
aGF0IHRoZSBjbGllbnQgaXMgc3VyZSB0aGUgbm9kZXMgZm9yIG9wZXJhdGlvbj1ub25lPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+
YWN0dWFsbHkgZXhpc3QuJm5ic3A7IEJlY2F1c2Ugb2YgdGhpcyBZQU5HIGRldGFpbCwgdGhlIGNs
aWVudCBjYW5ub3QgYmUgc3VyZSBzbyB1c2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPmRlZmF1bHQtb3BlcmF0aW9uPW5vbmUg
bWF5IG5vdCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPkkg
ZGlzYWdyZWUgd2l0aCB0aGlzIGNvbmNsdXNpb24uIEV2ZW4gdXNpbmcgZGVmYXVsdC1vcGVyYXRp
b249bm9uZSB0aGUgdHJhbnNhY3Rpb25zIG11c3QgYmUgZ3VhcmFudGVlZCB0byB3b3JrIGJ5IGEg
Y29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbi4gTlAgY29udGFpbmVycyBjYW5ub3QgYmUgY3JlYXRl
ZC9kZWxldGVkDQogaW4gYSBkZWVwZXIgc2Vuc2Ugb2YgdGhlIHdvcmQgc2luY2UgdGhleSBoYXZl
IHplcm8gaW5mb3JtYXRpb24gY29udGVudC4gVGhleSBjYW4gb25seSBiZSByZWZlcnJlZCB0by4g
QW55IG11c3Qgc3RhdGVtZW50cyB3aXRoaW4gdGhlIGNvbnRhaW5lciBtdXN0IGJlIGV2YWx1YXRl
ZCByZWdhcmRsZXNzIG9mIHRoZSBjbGllbnQgZXZlciBtZW50aW9uaW5nIHRoZSBjb250YWluZXIu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFu
UFNNVDtjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFu
UFNNVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpU
aW1lc05ld1JvbWFuUFNNVCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+SSBkbyBub3QgYWdyZWUgdGhhdCBkZWZhdWx0
LW9wZXJhdGlvbj1ub25lIGRvZXMgbm90IGFwcGx5IHRvIE5QIGNvbnRhaW5lcnMuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1Jv
bWFuUFNNVCI+VGhpcyBpcyB3aHkgaXQgd2FzIHN1Y2ggYSBiYWQgZGVjaXNpb24gdG8gc3ByZWFk
IGxpdHRsZSBwaWVjZXMgb2YgTkVUQ09ORjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPmFsbCBvdmVyIHRoZSBZQU5HIFJGQy4gUkZD
IDYyNDEgZGVmaW5lcyB0aGUgJ2RlZmF1bHQtb3BlcmF0aW9uJyBsZWFmPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+YW5kIGl0IGRv
ZXMgbm90IHNheSBhbnl0aGluZyBhYm91dCBzcGVjaWFsIHRyZWF0bWVudCBmb3IgTlAgY29udGFp
bmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3
Um9tYW5QU01UIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5i
c3A7Jm5ic3A7IG5vbmU6Jm5ic3A7IFRoZSB0YXJnZXQgZGF0YXN0b3JlIGlzIHVuYWZmZWN0ZWQg
YnkgdGhlIGNvbmZpZ3VyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4g
dGhlICZsdDtjb25maWcmZ3Q7IHBhcmFtZXRlciwgdW5sZXNzIGFuZCB1bnRpbCB0aGUgaW5jb21p
bmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbiBkYXRhIHVz
ZXMgdGhlICZxdW90O29wZXJhdGlvbiZxdW90OyBhdHRyaWJ1dGUgdG8gcmVxdWVzdDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIGRpZmZlcmVudCBvcGVyYXRpb24uJm5ic3A7IElm
IHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSAmbHQ7Y29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIgY29udGFpbnMgZGF0YSBmb3Igd2hpY2ggdGhlcmUg
aXMgbm90IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ycmVzcG9uZGluZyBs
ZXZlbCBpbiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSwgYW4gJmx0O3JwYy1lcnJvciZndDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgcmV0dXJuZWQgd2l0aCBhbiAmbHQ7ZXJyb3It
dGFnJmd0OyB2YWx1ZSBvZiBkYXRhLW1pc3NpbmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFVzaW5nICZxdW90O25vbmUmcXVvdDsgYWxsb3dzIG9wZXJhdGlvbnMgbGlrZSAmcXVv
dDtkZWxldGUmcXVvdDsgdG8gYXZvaWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
dW5pbnRlbnRpb25hbGx5IGNyZWF0aW5nIHRoZSBwYXJlbnQgaGllcmFyY2h5IG9mIHRoZSBlbGVt
ZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGJlIGRlbGV0ZWQuPG86cD48
L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21h
blBTTVQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQ7Y29sb3I6Izg4ODg4
OCI+L2phbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6VGltZXNO
ZXdSb21hblBTTVQ7Y29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVz
TmV3Um9tYW5QU01UIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01UIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCCAC33US70TWXCHMBA11z_--


From nobody Fri Jul 15 07:20:03 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3095212D0BA for ; Fri, 15 Jul 2016 07:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geyzyvvJRqWz for ; Fri, 15 Jul 2016 07:19:57 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50467127077 for ; Fri, 15 Jul 2016 07:19:57 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id o63so157651000vkg.1 for ; Fri, 15 Jul 2016 07:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bTVbKJNAPnHj+LP9LuPYTiV/PhrbVYyQ15YX3lAc59E=; b=0hT9qUijvhyioXZ+a8VleeBoIqmoAwlYx0O18BtCB+SbG51qKmuHGOIfvrXueH632A BwVnbxWhXfft39Gmk3aqZZF92KNejLbv6IXfZE3wPjAl/YuAB0F8C482AzkhZPP5L+x2 uzLrgj9yYqy7+g/x+FZH7ejD5O8XKT94aLRhb0ol7BDUXpGfq+BOG7QwGv95GjRk1Ugb BOWIEl/rlnVqlP1XyijYMBkhFr4OptLi89yv7nFIUUGNRopVuoe/ZTm1B5hAVU68a63r YOv1p4F9GM/kDS6Qy38rwdKLsAcXVEqOjTqyFd2ABmd1uY4ryS81I8PLY90iEIce+LGt klFg==
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; bh=bTVbKJNAPnHj+LP9LuPYTiV/PhrbVYyQ15YX3lAc59E=; b=OlKrpcDgUcf5yqUtGtmoOafszF2k/2z2ydaR2I+5VPx1B1619Bg2H1wqYAVkkaXtXw OylFFJwsiszYR5xdue1csfbtsGJOsluHdHA6p7vOLgmIKbcmyWoRKe9E+iK9Xd+Ccgtk K9gmbaWi+8oufsAjFJRaHYrM0Sp3UyleXXDr2ue6Rs/4CuR15O6gJp5XRNUzSqJ7AwhX bC25LJZZoydIiSdmE+DEta5bv2+D4Qta4DQ//f4NzUntU6D/4zSVNCoG5gJG3jw5Pyxy tY68stp3cQTvBkxr1S9V2Cd6mM5CVjSoqhkw6y6/9cUZ1Z056q+rnZ56aSH8X2Sd6ChJ 6CXg==
X-Gm-Message-State: ALyK8tJQ1TT7Erb3Sf+DJKrAoLCuDcp+CqVsF/Vk+Z28qZws/Mv89siUI8dQLcFKRw6xpky3ZkZvNaTKL4b6wQ==
X-Received: by 10.159.36.205 with SMTP id 71mr10509373uar.121.1468592396365; Fri, 15 Jul 2016 07:19:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Fri, 15 Jul 2016 07:19:55 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com>  
From: Andy Bierman 
Date: Fri, 15 Jul 2016 07:19:55 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Content-Type: multipart/alternative; boundary=001a113e5dde1b126c0537ad5089
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 14:20:00 -0000

--001a113e5dde1b126c0537ad5089
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 15, 2016 at 4:32 AM, Sterne, Jason (Nokia - CA) <
jason.sterne@nokia.com> wrote:

> When we say =E2=80=9CNP containers can be created/deleted=E2=80=9D I gene=
rally interpret
> that to mean that it is valid to have an operation=3D=E2=80=99delete=E2=
=80=99 (or create or
> remove or merge) on an NP container node in an  request
> (either directly or inherited).
>
>
>
> I don=E2=80=99t think there should be any real meaning to the existence/p=
resence
> (or not) of NP containers in a datastore.   But it does seem this isn=E2=
=80=99t
> very clearly laid out in the RFCs.
>
>
>
> They are pretty useful for data model organization (at least for humans
> looking at data/models).
>
>
>

The NETCONF RFC does not make any special conditions for creating or
deleting data.

IMO this is not even a problem because NETCONF has 2 sets of edit
operations.

If the client is 100% aware of the server behavior (defaults, deviations,
features, etc.)
it can use  create and delete, which are picky and will be rejected unless
the operation really is create or delete..

NETCONF also has merge and remove which are not picky.
These operations ALWAYS work even if the server has
deleted nodes, or defaults or whatever. So just use merge and remove
instead of create and delete.


Jason
>


Andy


>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Friday, July 15, 2016 3:25
> *To:* Jan Lindblad
> *Cc:* Xiang Li; Sterne, Jason (Nokia - CA); Netconf
> *Subject:* Re: [Netconf] What should a server response be?
>
>
>
> Hi,
>
>
>
> I do not like NP containers at all.
>
> They have so many special rules.
>
> I don't know what problem is being solved by having them at all.
>
> Also RFC 6241 defines NETCONF, not YANG.
>
>
>
> Even in the YANG 1.1 spec, it says MAY delete but does not say MAY create
> anywhere.
>
> YANG does not say NP containers cannot be created or deleted
>
> by the client.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Thu, Jul 14, 2016 at 11:46 PM, Jan Lindblad  wrote:
>
> In order to reach rough consensus on the interpretation of the
> default-operation=3Dnone sequence, I think we need to start with coming t=
o a
> common understanding of what NP containers are. Can NP containers be
> "created" and "deleted" just like P containers?
>
>
>
> Here's a test to see if there is any difference between the behavior of p
> and np containers:
>
>
>
> list t {
>
>     key a;
>
>     leaf a { type uint32; }
>
>     container np {
>
>         must "../a > 10";
>
>     }
>
>     container p {
>
>         presence "...";
>
>         must "../a > 20";
>
>     }
>
> }
>
>
>
> The config is initially empty. Now, would it be possible to
>
>
>
> a) create an instance with a =3D 5 if there is no mention of np and p in =
the
> edit-config?
>
> b) create an instance with a =3D 5 if np (but not p) is "created" in the
> edit-config?
>
> c) create an instance with a =3D 15 if there is no mention of np and p in
> the edit-config?
>
> d) create an instance with a =3D 15 if p is created in the edit-config?
>
>
>
> My own answer is that only operation c is allowed. "creation" of an NP
> container is irrelevant, while creation of a P container makes a
> difference. An NP container is simply a structural element, and does not
> need to be "created" to exist, but empty NP containers MAY not be reporte=
d
> since they are meaningless anyway.
>
>
>
> If must statements in np containers are in effect even if the client isn'=
t
> explicitly "creating" or mentioning the container, then I find it hard to
> understand the viewpoint that "creation" of NP containers makes any
> difference.
>
>
>
> /jan
>
>
>
> I guess I don=E2=80=99t really see NP-containers as =E2=80=9Cconfig=E2=80=
=9D.  They are just
> structure and filtered out when empty.  I don=E2=80=99t really see this a=
s the
> server =E2=80=9Cdeleting=E2=80=9D those containers.  It just suppresses t=
hem in
>  output.
>
> Please show me the RFC text that says the server can filter out NP
> containers.
>
> All config=3Dtrue data nodes are config.
>
>
>
> In a very technical sense, I suppose the above statement is correct. An N=
P
> container is of course config true if it sits in the config true part of
> the tree. At the same time I agree with Janson's view that NP containers
> are just structure, so the question of their "existence" is moot.
>
>
>
> Here's what RFC 6020, sec 7.5 says on the topic:
>
>
>
>    YANG supports two styles of containers, those that exist only for
>
>    organizing the hierarchy of data nodes, and those whose presence in
>
>    the configuration has an explicit meaning.
>
>
>
> So NP containers "exist only for organizing the hierarchy" while a P
> container "has an explicit meaning". I guess this implies NP containers
> having no meaning. Further down in 7.5.1, re P containers, it is noted th=
at:
>
>
>
>    In the second style, the presence of the container itself is
>
>    configuration data, representing a single bit of configuration data.
>
>    The container acts as both a configuration knob and a means of
>
>    organizing related configuration.  These containers are explicitly
>
>    created and deleted.
>
>
>
> Based on these fragments, I conclude that NP containers have zero bits of
> information. This means the existence/absence of an NP container cannot b=
e
> known/stored/remembered even internally by a conforming system. The
> existence/absence of an NP container is a moot question. It's a bit like
> asking for the value of a void function. It's there, it has a name, but n=
o
> value.
>
>
>
> Implementations that receive a  or  request that contain=
s
> an NP container will have to decide whether to include the NP container i=
n
> the response or not. Since the existence of the NP container cannot be re=
ad
> from a database/etc (it has zero bits of information), the implementation
> will have to use some other way to determine whether to include it or not=
.
>
>
>
> In order to make the life easier for implementors, the following MAY was
> introduced in sec 7.5.7:
>
>
>
>    A NETCONF server that replies to a  or  request MAY
>
>    choose not to send a container element if the container node does not
>
>    have the "presence" statement and no child nodes exist.
>
>
>
> So the NP container has to be included if it has children, or else the
> structural function of the container would be lost. If the NP container i=
s
> empty, it may or may not be sent. Since an NP container has zero bits of
> information, this decision would not be based on whether it has been
> previously "created" or "deleted", but on implementation considerations.
> One possible approach is to always include it, another to actually check =
if
> there are any children, and only return it then.
>
>
>
> Either way, NP containers alone have no meaning/information, they are onl=
y
> there for structure.
>
>
>
> A false must-stmt in an NP-container is still an error.
>
>
>
> Certainly. Must statements on an NP container are always evaluated, even
> if the container hasn't been "created" or mentioned by a client, and even
> if it has no child elements.
>
>
>
> As Lada has pointed out many times, the text about
>
> NP containers not being part of the data model is just wrong.
>
>
>
> I think the length of this discussion implies we should include this topi=
c
> in the upcoming YANG FAQ.
>
> The server should not error in the cases Mahesh & Einar show -> the
> presence/existence of NP-containers shouldn=E2=80=99t really affect behav=
ior (since
> they aren=E2=80=99t really config).
>
> I agree with the above.
>
> But I=E2=80=99m not positive what you mean by =E2=80=9Cmanager needs to g=
uard=E2=80=9D.  Do you
> agree that the server should not error in those cases below ?
>
> The YANG text says a server MAY delete an empty NP container.
>
> Using default-operation=3Dnone implies that the client is sure the nodes =
for
> operation=3Dnone
>
> actually exist.  Because of this YANG detail, the client cannot be sure s=
o
> using
>
> default-operation=3Dnone may not work.
>
>
>
> I disagree with this conclusion. Even using default-operation=3Dnone the
> transactions must be guaranteed to work by a conforming implementation. N=
P
> containers cannot be created/deleted in a deeper sense of the word since
> they have zero information content. They can only be referred to. Any mus=
t
> statements within the container must be evaluated regardless of the clien=
t
> ever mentioning the container.
>
>
>
>
>
>
>
> I do not agree that default-operation=3Dnone does not apply to NP contain=
ers.
>
>
>
> This is why it was such a bad decision to spread little pieces of NETCONF
>
> all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
>
> and it does not say anything about special treatment for NP containers.
>
>
>
>    none:  The target datastore is unaffected by the configuration
>
>             in the  parameter, unless and until the incoming
>
>             configuration data uses the "operation" attribute to request
>
>             a different operation.  If the configuration in the 
>
>             parameter contains data for which there is not a
>
>             corresponding level in the target datastore, an 
>
>             is returned with an  value of data-missing.
>
>             Using "none" allows operations like "delete" to avoid
>
>             unintentionally creating the parent hierarchy of the element
>
>             to be deleted.
>
>
>
>
>
> /jan
>
>
>
>
>
> Andy
>
>
>
>
>

--001a113e5dde1b126c0537ad5089
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jul 15, 2016 at 4:32 AM, Sterne, Jason (Nokia - CA) <ja=
son.sterne@nokia.com> wrote:




When we say =E2=80=9CNP c=
ontainers can be created/deleted=E2=80=9D I generally interpret that to mea=
n that it is valid to have an operation=3D=E2=80=99delete=E2=80=99 (or crea=
te or remove or
 merge) on an NP container node in an <edit-config> request (either d=
irectly or inherited).


=C2=A0


I don=E2=80=99t think the=
re should be any real meaning to the existence/presence (or not) of NP cont=
ainers in a datastore.=C2=A0=C2=A0 But it does seem this isn=E2=80=99t very=
 clearly
 laid out in the RFCs.


=C2=A0


They are pretty useful fo=
r data model organization (at least for humans looking at data/models).<=
/u>


=C2=A0
<=
/div>

The NETCONF RFC does not make a=
ny special conditions for creating or deleting data.

IMO this is not even a problem because NETCONF has 2 sets of edit operat=
ions.

If the client is 100% aware of the server be=
havior (defaults, deviations, features, etc.)
it can use =C2=A0cr=
eate and delete, which are picky and will be rejected unless
the =
operation really is create or delete..

NETCONF als=
o has merge and remove which are not picky.
These operations ALWA=
YS work even if the server has
deleted nodes, or defaults or what=
ever. So just use merge and remove
instead of create and delete.<=
/div>




Jason


Andy
=C2=A0
<=
u>


=C2=A0




From: Andy Bie=
rman [mailto:andy@y=
umaworks.com]


Sent: Friday, July 15, 2016 3:25

To: Jan Lindblad

Cc: Xiang Li; Sterne, Jason (Nokia - CA); Netconf

Subject: Re: [Netconf] What should a server response be?




=C2=A0




Hi,




=C2=A0






I do not like NP containers at all.





They have so many special rules.






I don't know what problem is being solved by hav=
ing them at all.






Also RFC 6241 defines NETCONF, not YANG.






=C2=A0






Even in the YANG 1.1 spec, it says MAY delete but do=
es not say MAY create anywhere.






YANG does not say NP containers cannot be created or=
 deleted






by the client.






=C2=A0






=C2=A0






Andy






=C2=A0








=C2=A0




On Thu, Jul 14, 2016 at 11:46 PM, Jan Lindblad <<=
a href=3D"mailto:janl@tail-f.com" target=3D"_blank">janl@tail-f.com>=
 wrote:




In order to reach rough consensus on the interpretat=
ion of the default-operation=3Dnone sequence, I think we need to start with=
 coming to a common understanding of what NP containers are. Can NP contain=
ers be "created" and "deleted" just
 like P containers?




=C2=A0






Here's a test to see if there is any difference =
between the behavior of p and np containers:






=C2=A0






list t {






=C2=A0 =C2=A0 key a;






=C2=A0 =C2=A0 leaf a { type uint32; }<=
/p>





=C2=A0 =C2=A0 container np {






=C2=A0 =C2=A0 =C2=A0 =C2=A0 must "../a > 10&=
quot;;






=C2=A0 =C2=A0 }






=C2=A0 =C2=A0 container p {






=C2=A0 =C2=A0 =C2=A0 =C2=A0 presence "..."=
;






=C2=A0 =C2=A0 =C2=A0 =C2=A0 must "../a > 20&=
quot;;






=C2=A0 =C2=A0 }






}






=C2=A0






The config is initially empty. Now, would it be poss=
ible to






=C2=A0






a) create an instance with a =3D 5 if there is no me=
ntion of np and p in the edit-config?






b) create an instance with a =3D 5 if np (but not p)=
 is "created" in the edit-config?






c) create an instance with a =3D 15 if there is no m=
ention of np and p in the edit-config?






d) create an instance with a =3D 15 if p is created =
in the edit-config?








=C2=A0








My own answer is that only operation c is allowed. &=
quot;creation" of an NP container is irrelevant, while creation of a P=
 container makes a difference. An NP container is simply a structural eleme=
nt, and does not need to be "created" to exist,
 but empty NP containers MAY not be reported since they are meaningless any=
way.






=C2=A0






If must statements in np containers are in effect ev=
en if the client isn't explicitly "creating" or mentioning th=
e container, then I find it hard to understand the viewpoint that "cre=
ation" of NP containers makes any difference.






=C2=A0






/jan






=C2=A0




































I guess I don=E2=80=99t r=
eally see NP-containers as =E2=80=9Cconfig=E2=80=9D.=C2=A0 They are just st=
ructure and filtered out when
 empty.=C2=A0 I don=E2=80=99t really see this as the server =E2=80=9Cdeleti=
ng=E2=80=9D those containers.=C2=A0 It just suppresses them in <get-conf=
ig> output. =C2=A0=C2=A0










Please show me the RFC text that says the server can filter out N=
P containers.






All config=3Dtrue data nodes are config.














=C2=A0






In a very technical sense, I suppose the above statement is corre=
ct. An NP container is of course config true if it sits in the config true =
part of the tree. At the same time I
 agree with Janson's view that NP containers are just structure, so the=
 question of their "existence" is moot.=C2=A0






=C2=A0






Here's what RFC 6020, sec 7.5 says on the topic:






=C2=A0






=C2=A0=C2=A0 YANG supports two styles =
of containers, those that exist only for


=C2=A0=C2=A0 organizing the hierarchy =
of data nodes, and those whose presence in


=C2=A0=C2=A0 the configuration has an =
explicit meaning.




=C2=A0








So NP containers "exist only for organizing the hierarchy&qu=
ot; while a P container "has an explicit meaning". I guess this i=
mplies NP containers having no meaning. Further down in
 7.5.1, re P containers, it is noted that:






=C2=A0






=C2=A0=C2=A0 In the second style, the =
presence of the container itself is


=C2=A0=C2=A0 configuration data, repre=
senting a single bit of configuration data.




=C2=A0=C2=A0 The container acts as bot=
h a configuration knob and a means of


=C2=A0=C2=A0 organizing related config=
uration.=C2=A0 These containers are explicitly


=C2=A0=C2=A0 created and deleted.






=C2=A0








Based on these fragments, I conclude that NP containers have zero=
 bits of information. This means the existence/absence of an NP container c=
annot be known/stored/remembered even
 internally by a conforming system. The existence/absence of an NP containe=
r is a moot question. It's a bit like asking for the value of a void fu=
nction. It's there, it has a name, but no value.





=C2=A0






Implementations that receive a <get> or <get-config> =
request that contains an NP container will have to decide whether to includ=
e the NP container in the response or not. Since
 the existence of the NP container cannot be read from a database/etc (it h=
as zero bits of information), the implementation will have to use some othe=
r way to determine whether to include it or not.






=C2=A0






In order to make the life easier for implementors, the following =
MAY was introduced in sec 7.5.7:






=C2=A0






=C2=A0=C2=A0 A NETCONF server that rep=
lies to a <get> or <get-config> request MAY


=C2=A0=C2=A0 choose not to send a cont=
ainer element if the container node does not


=C2=A0=C2=A0 have the "presence&q=
uot; statement and no child nodes exist.




=C2=A0








So the NP container has to be included if it has children, or els=
e the structural function of the container would be lost. If the NP contain=
er is empty, it may or may not be sent.
 Since an NP container has zero bits of information, this decision would no=
t be based on whether it has been previously "created" or "d=
eleted", but on implementation considerations. One possible approach i=
s to always include it, another to actually check if
 there are any children, and only return it then.






=C2=A0






Either way, NP containers alone have no meaning/information, they=
 are only there for structure.



















A false must-stmt in an NP-container is still an error.=













=C2=A0






Certainly. Must statements on an NP container are always evaluate=
d, even if the container hasn't been "created" or mentioned b=
y a client, and even if it has no child elements.



















As Lada has pointed out many times, the text about<=
/span>






NP containers not being part of the data model is just wrong.<=
/u>












=C2=A0






I think the length of this discussion implies we should include t=
his topic in the upcoming YANG FAQ.


















The server should not err=
or in the cases Mahesh & Einar show -> the presence/existence of NP-=
containers
 shouldn=E2=80=99t really affect behavior (since they aren=E2=80=99t really=
 config).=C2=A0
















I agree with the above.


















But I=E2=80=99m not posit=
ive what you mean by =E2=80=9Cmanager needs to guard=E2=80=9D.=C2=A0 Do you=
 agree that the server should
 not error in those cases below ?










The YANG text says a server MAY delete an empty NP container.<=
/u>






Using default-operation=3Dnone implies that the client is sure th=
e nodes for operation=3Dnone






actually exist.=C2=A0 Because of this YANG detail, the client can=
not be sure so using






default-operation=3Dnone may not work.












=C2=A0






I disagree with this conclusion. Even using default-operation=3Dn=
one the transactions must be guaranteed to work by a conforming implementat=
ion. NP containers cannot be created/deleted
 in a deeper sense of the word since they have zero information content. Th=
ey can only be referred to. Any must statements within the container must b=
e evaluated regardless of the client ever mentioning the container.<=
u>






=C2=A0












=C2=A0






=C2=A0






I do not agree that default-operation=3Dnone does not apply to NP=
 containers.






=C2=A0






This is why it was such a bad decision to spread little pieces of=
 NETCONF






all over the YANG RFC. RFC 6241 defines the 'default-operatio=
n' leaf






and it does not say anything about special treatment for NP conta=
iners.






=C2=A0






=C2=A0=C2=A0 none:=
=C2=A0 The target datastore is unaffected by the configuration


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in =
the <config> parameter, unless and until the incoming

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 con=
figuration data uses the "operation" attribute to request<=
u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a d=
ifferent operation.=C2=A0 If the configuration in the <config>=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 par=
ameter contains data for which there is not a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cor=
responding level in the target datastore, an <rpc-error>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is =
returned with an <error-tag> value of data-missing.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Usi=
ng "none" allows operations like "delete" to avoid


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uni=
ntentionally creating the parent hierarchy of the element

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to =
be deleted.






=C2=A0






=C2=A0












/jan






=C2=A0












=C2=A0






Andy










=C2=A0








=C2=A0












--001a113e5dde1b126c0537ad5089--


From nobody Fri Jul 15 10:08:25 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7655D12D0E9 for ; Fri, 15 Jul 2016 10:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcpXjvYkoCkf for ; Fri, 15 Jul 2016 10:08:22 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BAD12B055 for ; Fri, 15 Jul 2016 10:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10731; q=dns/txt; s=iport; t=1468602502; x=1469812102; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=ng6Hvim+gC+v9kFvqrUDzt/QsNyE7kUKi1dMHbxX3no=; b=BNWX6/JD7xg5RqGljqwHDoQaVLGh7t8BlXD3sosuH9NS4CMRV6srbawy 8DnWDXCPpdsmwU+PeM+y4U0+nYY8gLalPhtbazVYZg3o3xIJPrlY8//jj 0ZmK98huYMx2PCzj5uBBF5zhJ8UGqwMSm00yE+e59hbW0zLe4PP3Z77zv k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwBQBgF4lX/xbLJq1cgnCBJCpSrFqHF?= =?us-ascii?q?oUEgXuGGgKBZxQBAQEBAQEBZSeEXAEBBS1cHAMBAi8hLAIIBg0GAgEBiBIDF7s?= =?us-ascii?q?+DYQaAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqgXgIgk2CQ4FFWIU7BZNghQ00j?= =?us-ascii?q?ESCF4Frh2WFZYZdgUWHeR42g3U6MgGFHYE1AQEB?=
X-IronPort-AV: E=Sophos;i="5.28,368,1464652800";  d="scan'208,217";a="635735801"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2016 17:08:20 +0000
Received: from [10.61.215.20] ([10.61.215.20]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6FH8Jta003790 for ; Fri, 15 Jul 2016 17:08:19 GMT
References: 
To: NETCONF 
From: Benoit Claise 
X-Forwarded-Message-Id: 
Message-ID: <034335c8-d7d7-2589-3f10-ab3a0a4dd770@cisco.com>
Date: Fri, 15 Jul 2016 19:08:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A8F81E12C9B1EC1526B36521"
Archived-At: 
Subject: [Netconf] Fwd: Secdir (Re)review of draft-ietf-netconf-restconf-15:
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 17:08:23 -0000

This is a multi-part message in MIME format.
--------------A8F81E12C9B1EC1526B36521
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

FYI.

Regards, B.


-------- Forwarded Message --------
Subject: 	Secdir (Re)review of draft-ietf-netconf-restconf-15:
Resent-Date: 	Fri, 15 Jul 2016 05:24:30 -0700
Resent-From: 	alias-bounces@ietf.org, frank.xialiang@huawei.com
Resent-To: 	andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, 
mjethanandani@gmail.com, mehmet.ersue@nokia.com, bclaise@cisco.com, 
joelja@bogus.com, draft-ietf-netconf-restconf.all@ietf.org
Date: 	Fri, 15 Jul 2016 12:24:07 +0000
From: 	Xialiang (Frank) 
To: 	'iesg@ietf.org' , 'secdir@ietf.org' 
, draft-ietf-netconf-restconf.all@tools.ietf.org 




Hello,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document describes an HTTP-based protocol that provides a 
programmatic interface for accessing data defined in YANG, using the 
datastore concepts defined in NETCONF.

I have reviewed draft-ietf-netconf-restconf-09 as the Secdir before. My 
general thoughts about it is:

Firstly, the document appears in reasonably good shape.

Secondly, in general, the RESTCONF is an application protocol layered on 
the HTTP protocol. As mentioned in the document, just using the HTTPS 
(with TLS) can address most of the security issues such as 
confidentiality, integrity, authentication, etc. In other words, 
RESTCONF is designed inherently based on a good security base.

Now, after several rounds of update, this draft has became better in the 
aspect of security considerations. I don’t see further security issues 
in addition to the description in the sections of “Transport Protocol 
Requirements” and “Security Considerations”.

In summary, I think this draft is Ready!

Thanks!

B.R.

Frank


--------------A8F81E12C9B1EC1526B36521
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  

    
  
  
    FYI.

    

    Regards, B.

    


      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            Secdir (Re)review of draft-ietf-netconf-restconf-15:
          

          

            Resent-Date:
            
            Fri, 15 Jul 2016 05:24:30 -0700
          

          

            Resent-From:
            
            alias-bounces@ietf.org, frank.xialiang@huawei.com
          

          

            Resent-To:
            
            andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net,
              mjethanandani@gmail.com, mehmet.ersue@nokia.com,
              bclaise@cisco.com, joelja@bogus.com,
              draft-ietf-netconf-restconf.all@ietf.org
          

          

            Date: 
            Fri, 15 Jul 2016 12:24:07 +0000
          

          

            From: 
            Xialiang (Frank) <frank.xialiang@huawei.com>
          

          

            To: 
            'iesg@ietf.org' <iesg@ietf.org>, 'secdir@ietf.org'
              <secdir@ietf.org>,
              draft-ietf-netconf-restconf.all@tools.ietf.org
              <draft-ietf-netconf-restconf.all@tools.ietf.org>
          

        
      

      

      

      
      
      
      

        
Hello,

        
I have reviewed this
            document as part of the security directorate's ongoing
            effort to review all IETF documents being processed by the
            IESG.  These comments were written primarily for the benefit
            of the security area directors.  Document editors and WG
            chairs should treat these comments just like any other last
            call comments.

        
 

        
This document describes
            an HTTP-based protocol that provides a programmatic
            interface for accessing data defined in YANG, using the
            datastore concepts defined in NETCONF.

        
 

        
I have reviewed
            draft-ietf-netconf-restconf-09 as the Secdir before. My
            general thoughts about it is:

        
 

        
Firstly, the document
            appears in reasonably good shape.

        
 

        
Secondly, in general,
            the RESTCONF is an application protocol layered on the HTTP
            protocol. As mentioned in the document, just using the HTTPS
            (with TLS) can address most of the security issues such as
            confidentiality, integrity, authentication, etc. In other
            words, RESTCONF is designed inherently based on a good
            security base.

        
 

        
 

        
Now, after several
            rounds of update, this draft has became better in the aspect
            of security considerations. I don’t see further security
            issues in addition to the description in the sections of
            “Transport Protocol Requirements” and “Security
            Considerations”. 

        
 

        
In summary, I think this
            draft is Ready!

        
 

        
Thanks!

        
 

        
B.R.

        
Frank

        
 

        
 

        
 

      

    

  


--------------A8F81E12C9B1EC1526B36521--


From nobody Fri Jul 15 11:11:40 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BD512B04F for ; Fri, 15 Jul 2016 11:11:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 wjE0qgCR10rD for ; Fri, 15 Jul 2016 11:11:37 -0700 (PDT)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B0712D0AA for ; Fri, 15 Jul 2016 11:11:37 -0700 (PDT)
Received: from [192.168.10.101] ([24.13.90.46]) by p3plsmtpa12-04.prod.phx3.secureserver.net with  id K6Bb1t005100Es8016Bbmy; Fri, 15 Jul 2016 11:11:37 -0700
To: Jan Lindblad , Andy Bierman , "Sterne, Jason (Nokia - CA)" 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com>
From: Xiang Li 
Message-ID: <57892746.5020903@seguesoft.com>
Date: Fri, 15 Jul 2016 13:11:18 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com>
Content-Type: multipart/alternative; boundary="------------040403030402040401030705"
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 18:11:40 -0000

This is a multi-part message in MIME format.
--------------040403030402040401030705
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/15/2016 1:46 AM, Jan Lindblad wrote:
> In order to reach rough consensus on the interpretation of the 
> default-operation=none sequence, I think we need to start with coming 
> to a common understanding of what NP containers are. Can NP containers 
> be "created" and "deleted" just like P containers?
>
> Here's a test to see if there is any difference between the behavior 
> of p and np containers:
>
> list t {
>     key a;
>     leaf a { type uint32; }
>     container np {
>         must "../a > 10";
>     }
>     container p {
>         presence "...";
>         must "../a > 20";
>     }
> }
>
> The config is initially empty. Now, would it be possible to
>
> a) create an instance with a = 5 if there is no mention of np and p in 
> the edit-config?
> b) create an instance with a = 5 if np (but not p) is "created" in the 
> edit-config?
> c) create an instance with a = 15 if there is no mention of np and p 
> in the edit-config?
> d) create an instance with a = 15 if p is created in the edit-config?
> My own answer is that only operation c is allowed. "creation" of an NP 
> container is irrelevant, while creation of a P container makes a 
> difference.

Yes I agree


> An NP container is simply a structural element, and does not need to 
> be "created" to exist,

I understand the "does not need to be 'created' to exist" part. The 
confusion arises about what is a compliant
implementation when a client does want to create it explicitly for 
whatever reason. Using your example
(a very good example, by the way)

e) create with a = 15,  and also create np  explicitly

and then follows up with an additional edit-config
f)  merge with a = 15, and create np explicitly again


should a compliant server reject f) or not?

> but empty NP containers MAY not be reported since they are meaningless 
> anyway.
>
I agree

> If must statements in np containers are in effect even if the client 
> isn't explicitly "creating" or mentioning the container, then I find 
> it hard to understand the viewpoint that "creation" of NP containers 
> makes any difference.
>

It doesn't. What I am trying to figure out is  how a compliant server 
implementation
  should handle  the "operation"  on a NP container node in a 
.

-Xiang



> /jan
>
>>>         I guess I don’t really see NP-containers as “configâ€. They
>>>         are just structure and filtered out when empty.  I don’t
>>>         really see this as the server “deleting†those containers. 
>>>         It just suppresses them in  output.
>>>
>>>     Please show me the RFC text that says the server can filter out
>>>     NP containers.
>>>     All config=true data nodes are config.
>>
>>     In a very technical sense, I suppose the above statement is
>>     correct. An NP container is of course config true if it sits in
>>     the config true part of the tree. At the same time I agree with
>>     Janson's view that NP containers are just structure, so the
>>     question of their "existence" is moot.
>>
>>     Here's what RFC 6020, sec 7.5 says on the topic:
>>
>>         YANG supports two styles of containers, those that exist only for
>>         organizing the hierarchy of data nodes, and those whose presence in
>>         the configuration has an explicit meaning.
>>
>>
>>     So NP containers "exist only for organizing the hierarchy" while
>>     a P container "has an explicit meaning". I guess this implies NP
>>     containers having no meaning. Further down in 7.5.1, re P
>>     containers, it is noted that:
>>
>>         In the second style, the presence of the container itself is
>>         configuration data, representing a single bit of configuration data.
>>
>>         The container acts as both a configuration knob and a means of
>>         organizing related configuration.  These containers are explicitly
>>         created and deleted.
>>
>>
>>     Based on these fragments, I conclude that NP containers have zero
>>     bits of information. This means the existence/absence of an NP
>>     container cannot be known/stored/remembered even internally by a
>>     conforming system. The existence/absence of an NP container is a
>>     moot question. It's a bit like asking for the value of a void
>>     function. It's there, it has a name, but no value.
>>
>>     Implementations that receive a  or  request that
>>     contains an NP container will have to decide whether to include
>>     the NP container in the response or not. Since the existence of
>>     the NP container cannot be read from a database/etc (it has zero
>>     bits of information), the implementation will have to use some
>>     other way to determine whether to include it or not.
>>
>>     In order to make the life easier for implementors, the following
>>     MAY was introduced in sec 7.5.7:
>>
>>         A NETCONF server that replies to a  or  request MAY
>>         choose not to send a container element if the container node does not
>>         have the "presence" statement and no child nodes exist.
>>
>>
>>     So the NP container has to be included if it has children, or
>>     else the structural function of the container would be lost. If
>>     the NP container is empty, it may or may not be sent. Since an NP
>>     container has zero bits of information, this decision would not
>>     be based on whether it has been previously "created" or
>>     "deleted", but on implementation considerations. One possible
>>     approach is to always include it, another to actually check if
>>     there are any children, and only return it then.
>>
>>     Either way, NP containers alone have no meaning/information, they
>>     are only there for structure.
>>
>>>     A false must-stmt in an NP-container is still an error.
>>
>>     Certainly. Must statements on an NP container are always
>>     evaluated, even if the container hasn't been "created" or
>>     mentioned by a client, and even if it has no child elements.
>>
>>>     As Lada has pointed out many times, the text about
>>>     NP containers not being part of the data model is just wrong.
>>
>>     I think the length of this discussion implies we should include
>>     this topic in the upcoming YANG FAQ.
>>>
>>>         The server should not error in the cases Mahesh & Einar show
>>>         -> the presence/existence of NP-containers shouldn’t really
>>>         affect behavior (since they aren’t really config).
>>>
>>     I agree with the above.
>>>
>>>         But I’m not positive what you mean by “manager needs to
>>>         guardâ€. Do you agree that the server should not error in
>>>         those cases below ?
>>>
>>>     The YANG text says a server MAY delete an empty NP container.
>>>     Using default-operation=none implies that the client is sure the
>>>     nodes for operation=none
>>>     actually exist.  Because of this YANG detail, the client cannot
>>>     be sure so using
>>>     default-operation=none may not work.
>>
>>     I disagree with this conclusion. Even using
>>     default-operation=none the transactions must be guaranteed to
>>     work by a conforming implementation. NP containers cannot be
>>     created/deleted in a deeper sense of the word since they have
>>     zero information content. They can only be referred to. Any must
>>     statements within the container must be evaluated regardless of
>>     the client ever mentioning the container.
>>
>>
>>
>> I do not agree that default-operation=none does not apply to NP 
>> containers.
>>
>> This is why it was such a bad decision to spread little pieces of NETCONF
>> all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
>> and it does not say anything about special treatment for NP containers.
>>
>>     none:  The target datastore is unaffected by the configuration
>>              in the  parameter, unless and until the incoming
>>              configuration data uses the "operation" attribute to request
>>              a different operation.  If the configuration in the 
>>              parameter contains data for which there is not a
>>              corresponding level in the target datastore, an 
>>              is returned with an  value of data-missing.
>>              Using "none" allows operations like "delete" to avoid
>>              unintentionally creating the parent hierarchy of the element
>>              to be deleted.
>>
>>     /jan
>>
>>
>> Andy
>

--------------040403030402040401030705
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/15/2016 1:46 AM, Jan Lindblad
      wrote:

    

    

      
      In order to reach rough consensus on the interpretation of the
      default-operation=none sequence, I think we need to start with
      coming to a common understanding of what NP containers are. Can NP
      containers be "created" and "deleted" just like P containers?
      


      

      
Here's a test to see if there is any difference
        between the behavior of p and np containers:

      


      

      
list t {

      
    key a;

      
    leaf a { type uint32; }

      
    container np {

      
        must "../a > 10";

      
    }

      
    container p {

      
        presence "...";

      
        must "../a > 20";

      
    }

      
}

      


      

      
The config is initially empty. Now, would it be
        possible to

      


      

      
a) create an instance with a = 5 if there is no
        mention of np and p in the edit-config?

      
b) create an instance with a = 5 if np (but not p)
        is "created" in the edit-config?

      
c) create an instance with a = 15 if there is no
        mention of np and p in the edit-config?

      
d) create an instance with a = 15 if p is created in
        the edit-config?

    

    

      
My own answer is that only operation c is allowed.
        "creation" of an NP container is irrelevant, while creation of a
        P container makes a difference.

    

    

    Yes I agree 

    

    

    

      
 An NP container is simply a structural element, and
        does not need to be "created" to exist,

    

    

    I understand the "does not need to be 'created' to exist" part. The
    confusion arises about what is a compliant 

    implementation when a client does want to create it explicitly for
    whatever reason. Using your example 

    (a very good example, by the way)

    

    e) create with a = 15,  and also create np  explicitly

    

    and then follows up with an additional edit-config

    f)  merge with a = 15, and create np explicitly again 

    

    

    should a compliant server reject f) or not?

    

    

      
 but empty NP containers MAY not be reported since
        they are meaningless anyway.

      


      

    

    I agree 

    

    

      
If must statements in np containers are in effect
        even if the client isn't explicitly "creating" or mentioning the
        container, then I find it hard to understand the viewpoint that
        "creation" of NP containers makes any difference.

      


      

    

    

    It doesn't. What I am trying to figure out is  how a compliant
    server implementation

     should handle  the "operation"  on a NP container node in a
    <edit-config>.  

    

    -Xiang

    

    

    

    

      
/jan

      


      

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      
I
                                          guess I don’t really see
                                          NP-containers as “configâ€. 
                                          They are just structure and
                                          filtered out when empty.  I
                                          don’t really see this as the
                                          server “deleting†those
                                          containers.  It just
                                          suppresses them in
                                          <get-config> output.   

                                    

                                  

                                

                                
Please show me the RFC
                                  text that says the server can filter
                                  out NP containers.

                                
All config=true data nodes
                                  are config.

                              

                            

                          

                        

                        


                        

                        
In a very technical sense, I
                          suppose the above statement is correct. An NP
                          container is of course config true if it sits
                          in the config true part of the tree. At the
                          same time I agree with Janson's view that NP
                          containers are just structure, so the question
                          of their "existence" is moot. 

                        


                        

                        
Here's what RFC 6020, sec 7.5 says
                          on the topic:

                        


                        

                        

                          
   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.


                          


                          

                        

                        
So NP containers "exist only for
                          organizing the hierarchy" while a P container
                          "has an explicit meaning". I guess this
                          implies NP containers having no meaning.
                          Further down in 7.5.1, re P containers, it is
                          noted that:

                        


                        

                        

                          
   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.


                          

                            
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.


                          

                          


                          

                        

                        
Based on these fragments, I
                          conclude that NP containers have zero bits of
                          information. This means the existence/absence
                          of an NP container cannot be
                          known/stored/remembered even internally by a
                          conforming system. The existence/absence of an
                          NP container is a moot question. It's a bit
                          like asking for the value of a void function.
                          It's there, it has a name, but no value.

                        


                        

                        
Implementations that receive a
                          <get> or <get-config> request that
                          contains an NP container will have to decide
                          whether to include the NP container in the
                          response or not. Since the existence of the NP
                          container cannot be read from a database/etc
                          (it has zero bits of information), the
                          implementation will have to use some other way
                          to determine whether to include it or not.

                        


                        

                        
In order to make the life easier
                          for implementors, the following MAY was
                          introduced in sec 7.5.7:

                        


                        

                        

                          
   A NETCONF server that replies to a <get> or <get-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.

                          


                          

                        

                        
So the NP container has to be
                          included if it has children, or else the
                          structural function of the container would be
                          lost. If the NP container is empty, it may or
                          may not be sent. Since an NP container has
                          zero bits of information, this decision would
                          not be based on whether it has been previously
                          "created" or "deleted", but on implementation
                          considerations. One possible approach is to
                          always include it, another to actually check
                          if there are any children, and only return it
                          then.

                        


                        

                        
Either way, NP containers alone
                          have no meaning/information, they are only
                          there for structure.

                        

                        

                          

                            

                              

                                
A false must-stmt in an
                                  NP-container is still an error.

                              

                            

                          

                        

                        


                        

                        
Certainly. Must statements on an
                          NP container are always evaluated, even if the
                          container hasn't been "created" or mentioned
                          by a client, and even if it has no child
                          elements.

                        

                        

                          

                            

                              

                                
As Lada has pointed out
                                  many times, the text about

                                
NP containers not being
                                  part of the data model is just wrong.

                              

                            

                          

                        

                        


                        

                        
I think the length of this
                          discussion implies we should include this
                          topic in the upcoming YANG FAQ.

                        

                          

                            

                              

                                

                                  

                                    

                                      
The
                                          server should not error in the
                                          cases Mahesh & Einar show
                                          -> the presence/existence
                                          of NP-containers shouldn’t
                                          really affect behavior (since
                                          they aren’t really config). 

                                    

                                  

                                

                              

                            

                          

                        

                        I agree with the above.

                        

                          

                            

                              

                                

                                  

                                    

                                      
But
                                          I’m not positive what you mean
                                          by “manager needs to guardâ€. 
                                          Do you agree that the server
                                          should not error in those
                                          cases below ?

                                    

                                  

                                

                                
The YANG text says a
                                  server MAY delete an empty NP
                                  container.

                                
Using
                                  default-operation=none implies that
                                  the client is sure the nodes for
                                  operation=none

                                
actually exist.  Because
                                  of this YANG detail, the client cannot
                                  be sure so using

                                
default-operation=none may
                                  not work.

                              

                            

                          

                        

                        


                        

                        
I disagree with this conclusion.
                          Even using default-operation=none the
                          transactions must be guaranteed to work by a
                          conforming implementation. NP containers
                          cannot be created/deleted in a deeper sense of
                          the word since they have zero information
                          content. They can only be referred to. Any
                          must statements within the container must be
                          evaluated regardless of the client ever
                          mentioning the container.

                        
                            


                            

                          

                    

                  

                  


                  

                  


                  

                  
I do not agree that
                    default-operation=none does not apply to NP
                    containers.

                  


                  

                  
This is why it was such a bad decision
                    to spread little pieces of NETCONF

                  
all over the YANG RFC. RFC 6241 defines
                    the 'default-operation' leaf

                  
and it does not say anything about
                    special treatment for NP containers.

                  


                  

                  

                    
   none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


                  

                  


                  

                  
 

                  

                    

                      

                            
/jan

                            


                            

                          

                    

                  

                

                

              

              
Andy

            

          

        

        

      

    

  


--------------040403030402040401030705--


From nobody Fri Jul 15 11:37:44 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B412812D18B for ; Fri, 15 Jul 2016 11:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 kG8q6A6l9ZEV for ; Fri, 15 Jul 2016 11:37:40 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16D212D149 for ; Fri, 15 Jul 2016 11:37:39 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id BA6ECBEDEC9BC; Fri, 15 Jul 2016 18:37:35 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6FIbbWT006899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 18:37:38 GMT
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6FIbbbM024857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Jul 2016 18:37:37 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 15 Jul 2016 14:37:37 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Xiang Li , Jan Lindblad , "Andy Bierman" 
Thread-Topic: [Netconf] What should a server response be?
Thread-Index: AQHR3esI0j4IVR1/2kW9+f8gjxD6tKAYQ0SQgABICoD//73wYIAARsmAgAE80QWAAAaIwA==
Date: Fri, 15 Jul 2016 18:37:36 +0000
Message-ID: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>
In-Reply-To: <57892746.5020903@seguesoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCCB2EAUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 18:37:43 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCCB2EAUS70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KGYpIHNob3VsZCBiZSBhY2NlcHRlZCB3aXRob3V0IGFuIGVycm9yIElNTy4gICBUaGUgcHJlc2Vu
Y2UvZXhpc3RlbmNlIChvciBub3QpIG9mIGFuIE5QLWNvbnRhaW5lciBzaG91bGQgbm90IGFmZmVj
dCB0aGUgYmVoYXZpb3IuICAgTWF5YmUgdGhhdCBpc27igJl0IHNwZWxsZWQgb3V0IGluIHRoZSBS
RkNzIGJ1dCBJIGhhdmUgbXkgZG91YnRzIG1hbnkgaW1wbGVtZW50YXRpb25zIHdvdWxkIHJlamVj
dCAoZikuDQoNCkZyb206IFhpYW5nIExpIFttYWlsdG86eGlhbmdsaUBzZWd1ZXNvZnQuY29tXQ0K
U2VudDogRnJpZGF5LCBKdWx5IDE1LCAyMDE2IDE0OjExDQpUbzogSmFuIExpbmRibGFkOyBBbmR5
IEJpZXJtYW47IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpDQpDYzogTmV0Y29uZg0KU3ViamVj
dDogUmU6IFtOZXRjb25mXSBXaGF0IHNob3VsZCBhIHNlcnZlciByZXNwb25zZSBiZT8NCg0KT24g
Ny8xNS8yMDE2IDE6NDYgQU0sIEphbiBMaW5kYmxhZCB3cm90ZToNCkluIG9yZGVyIHRvIHJlYWNo
IHJvdWdoIGNvbnNlbnN1cyBvbiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGRlZmF1bHQtb3Bl
cmF0aW9uPW5vbmUgc2VxdWVuY2UsIEkgdGhpbmsgd2UgbmVlZCB0byBzdGFydCB3aXRoIGNvbWlu
ZyB0byBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgTlAgY29udGFpbmVycyBhcmUuIENh
biBOUCBjb250YWluZXJzIGJlICJjcmVhdGVkIiBhbmQgImRlbGV0ZWQiIGp1c3QgbGlrZSBQIGNv
bnRhaW5lcnM/DQoNCkhlcmUncyBhIHRlc3QgdG8gc2VlIGlmIHRoZXJlIGlzIGFueSBkaWZmZXJl
bmNlIGJldHdlZW4gdGhlIGJlaGF2aW9yIG9mIHAgYW5kIG5wIGNvbnRhaW5lcnM6DQoNCmxpc3Qg
dCB7DQogICAga2V5IGE7DQogICAgbGVhZiBhIHsgdHlwZSB1aW50MzI7IH0NCiAgICBjb250YWlu
ZXIgbnAgew0KICAgICAgICBtdXN0ICIuLi9hID4gMTAiOw0KICAgIH0NCiAgICBjb250YWluZXIg
cCB7DQogICAgICAgIHByZXNlbmNlICIuLi4iOw0KICAgICAgICBtdXN0ICIuLi9hID4gMjAiOw0K
ICAgIH0NCn0NCg0KVGhlIGNvbmZpZyBpcyBpbml0aWFsbHkgZW1wdHkuIE5vdywgd291bGQgaXQg
YmUgcG9zc2libGUgdG8NCg0KYSkgY3JlYXRlIGFuIGluc3RhbmNlIHdpdGggYSA9IDUgaWYgdGhl
cmUgaXMgbm8gbWVudGlvbiBvZiBucCBhbmQgcCBpbiB0aGUgZWRpdC1jb25maWc/DQpiKSBjcmVh
dGUgYW4gaW5zdGFuY2Ugd2l0aCBhID0gNSBpZiBucCAoYnV0IG5vdCBwKSBpcyAiY3JlYXRlZCIg
aW4gdGhlIGVkaXQtY29uZmlnPw0KYykgY3JlYXRlIGFuIGluc3RhbmNlIHdpdGggYSA9IDE1IGlm
IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgbnAgYW5kIHAgaW4gdGhlIGVkaXQtY29uZmlnPw0KZCkg
Y3JlYXRlIGFuIGluc3RhbmNlIHdpdGggYSA9IDE1IGlmIHAgaXMgY3JlYXRlZCBpbiB0aGUgZWRp
dC1jb25maWc/DQpNeSBvd24gYW5zd2VyIGlzIHRoYXQgb25seSBvcGVyYXRpb24gYyBpcyBhbGxv
d2VkLiAiY3JlYXRpb24iIG9mIGFuIE5QIGNvbnRhaW5lciBpcyBpcnJlbGV2YW50LCB3aGlsZSBj
cmVhdGlvbiBvZiBhIFAgY29udGFpbmVyIG1ha2VzIGEgZGlmZmVyZW5jZS4NCg0KWWVzIEkgYWdy
ZWUNCg0KDQoNCkFuIE5QIGNvbnRhaW5lciBpcyBzaW1wbHkgYSBzdHJ1Y3R1cmFsIGVsZW1lbnQs
IGFuZCBkb2VzIG5vdCBuZWVkIHRvIGJlICJjcmVhdGVkIiB0byBleGlzdCwNCg0KSSB1bmRlcnN0
YW5kIHRoZSAiZG9lcyBub3QgbmVlZCB0byBiZSAnY3JlYXRlZCcgdG8gZXhpc3QiIHBhcnQuIFRo
ZSBjb25mdXNpb24gYXJpc2VzIGFib3V0IHdoYXQgaXMgYSBjb21wbGlhbnQNCmltcGxlbWVudGF0
aW9uIHdoZW4gYSBjbGllbnQgZG9lcyB3YW50IHRvIGNyZWF0ZSBpdCBleHBsaWNpdGx5IGZvciB3
aGF0ZXZlciByZWFzb24uIFVzaW5nIHlvdXIgZXhhbXBsZQ0KKGEgdmVyeSBnb29kIGV4YW1wbGUs
IGJ5IHRoZSB3YXkpDQoNCmUpIGNyZWF0ZSB3aXRoIGEgPSAxNSwgIGFuZCBhbHNvIGNyZWF0ZSBu
cCAgZXhwbGljaXRseQ0KDQphbmQgdGhlbiBmb2xsb3dzIHVwIHdpdGggYW4gYWRkaXRpb25hbCBl
ZGl0LWNvbmZpZw0KZikgIG1lcmdlIHdpdGggYSA9IDE1LCBhbmQgY3JlYXRlIG5wIGV4cGxpY2l0
bHkgYWdhaW4NCg0KDQpzaG91bGQgYSBjb21wbGlhbnQgc2VydmVyIHJlamVjdCBmKSBvciBub3Q/
DQoNCg0KYnV0IGVtcHR5IE5QIGNvbnRhaW5lcnMgTUFZIG5vdCBiZSByZXBvcnRlZCBzaW5jZSB0
aGV5IGFyZSBtZWFuaW5nbGVzcyBhbnl3YXkuDQoNCkkgYWdyZWUNCg0KDQpJZiBtdXN0IHN0YXRl
bWVudHMgaW4gbnAgY29udGFpbmVycyBhcmUgaW4gZWZmZWN0IGV2ZW4gaWYgdGhlIGNsaWVudCBp
c24ndCBleHBsaWNpdGx5ICJjcmVhdGluZyIgb3IgbWVudGlvbmluZyB0aGUgY29udGFpbmVyLCB0
aGVuIEkgZmluZCBpdCBoYXJkIHRvIHVuZGVyc3RhbmQgdGhlIHZpZXdwb2ludCB0aGF0ICJjcmVh
dGlvbiIgb2YgTlAgY29udGFpbmVycyBtYWtlcyBhbnkgZGlmZmVyZW5jZS4NCg0KDQpJdCBkb2Vz
bid0LiBXaGF0IEkgYW0gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaXMgIGhvdyBhIGNvbXBsaWFudCBz
ZXJ2ZXIgaW1wbGVtZW50YXRpb24NCiBzaG91bGQgaGFuZGxlICB0aGUgIm9wZXJhdGlvbiIgIG9u
IGEgTlAgY29udGFpbmVyIG5vZGUgaW4gYSA8ZWRpdC1jb25maWc+Lg0KDQotWGlhbmcNCg0KDQoN
Cg0KL2phbg0KDQpJIGd1ZXNzIEkgZG9u4oCZdCByZWFsbHkgc2VlIE5QLWNvbnRhaW5lcnMgYXMg
4oCcY29uZmln4oCdLiAgVGhleSBhcmUganVzdCBzdHJ1Y3R1cmUgYW5kIGZpbHRlcmVkIG91dCB3
aGVuIGVtcHR5LiAgSSBkb27igJl0IHJlYWxseSBzZWUgdGhpcyBhcyB0aGUgc2VydmVyIOKAnGRl
bGV0aW5n4oCdIHRob3NlIGNvbnRhaW5lcnMuICBJdCBqdXN0IHN1cHByZXNzZXMgdGhlbSBpbiA8
Z2V0LWNvbmZpZz4gb3V0cHV0Lg0KUGxlYXNlIHNob3cgbWUgdGhlIFJGQyB0ZXh0IHRoYXQgc2F5
cyB0aGUgc2VydmVyIGNhbiBmaWx0ZXIgb3V0IE5QIGNvbnRhaW5lcnMuDQpBbGwgY29uZmlnPXRy
dWUgZGF0YSBub2RlcyBhcmUgY29uZmlnLg0KDQpJbiBhIHZlcnkgdGVjaG5pY2FsIHNlbnNlLCBJ
IHN1cHBvc2UgdGhlIGFib3ZlIHN0YXRlbWVudCBpcyBjb3JyZWN0LiBBbiBOUCBjb250YWluZXIg
aXMgb2YgY291cnNlIGNvbmZpZyB0cnVlIGlmIGl0IHNpdHMgaW4gdGhlIGNvbmZpZyB0cnVlIHBh
cnQgb2YgdGhlIHRyZWUuIEF0IHRoZSBzYW1lIHRpbWUgSSBhZ3JlZSB3aXRoIEphbnNvbidzIHZp
ZXcgdGhhdCBOUCBjb250YWluZXJzIGFyZSBqdXN0IHN0cnVjdHVyZSwgc28gdGhlIHF1ZXN0aW9u
IG9mIHRoZWlyICJleGlzdGVuY2UiIGlzIG1vb3QuDQoNCkhlcmUncyB3aGF0IFJGQyA2MDIwLCBz
ZWMgNy41IHNheXMgb24gdGhlIHRvcGljOg0KDQoNCiAgIFlBTkcgc3VwcG9ydHMgdHdvIHN0eWxl
cyBvZiBjb250YWluZXJzLCB0aG9zZSB0aGF0IGV4aXN0IG9ubHkgZm9yDQoNCiAgIG9yZ2FuaXpp
bmcgdGhlIGhpZXJhcmNoeSBvZiBkYXRhIG5vZGVzLCBhbmQgdGhvc2Ugd2hvc2UgcHJlc2VuY2Ug
aW4NCg0KICAgdGhlIGNvbmZpZ3VyYXRpb24gaGFzIGFuIGV4cGxpY2l0IG1lYW5pbmcuDQoNClNv
IE5QIGNvbnRhaW5lcnMgImV4aXN0IG9ubHkgZm9yIG9yZ2FuaXppbmcgdGhlIGhpZXJhcmNoeSIg
d2hpbGUgYSBQIGNvbnRhaW5lciAiaGFzIGFuIGV4cGxpY2l0IG1lYW5pbmciLiBJIGd1ZXNzIHRo
aXMgaW1wbGllcyBOUCBjb250YWluZXJzIGhhdmluZyBubyBtZWFuaW5nLiBGdXJ0aGVyIGRvd24g
aW4gNy41LjEsIHJlIFAgY29udGFpbmVycywgaXQgaXMgbm90ZWQgdGhhdDoNCg0KDQogICBJbiB0
aGUgc2Vjb25kIHN0eWxlLCB0aGUgcHJlc2VuY2Ugb2YgdGhlIGNvbnRhaW5lciBpdHNlbGYgaXMN
Cg0KICAgY29uZmlndXJhdGlvbiBkYXRhLCByZXByZXNlbnRpbmcgYSBzaW5nbGUgYml0IG9mIGNv
bmZpZ3VyYXRpb24gZGF0YS4NCg0KICAgVGhlIGNvbnRhaW5lciBhY3RzIGFzIGJvdGggYSBjb25m
aWd1cmF0aW9uIGtub2IgYW5kIGEgbWVhbnMgb2YNCg0KICAgb3JnYW5pemluZyByZWxhdGVkIGNv
bmZpZ3VyYXRpb24uICBUaGVzZSBjb250YWluZXJzIGFyZSBleHBsaWNpdGx5DQoNCiAgIGNyZWF0
ZWQgYW5kIGRlbGV0ZWQuDQoNCkJhc2VkIG9uIHRoZXNlIGZyYWdtZW50cywgSSBjb25jbHVkZSB0
aGF0IE5QIGNvbnRhaW5lcnMgaGF2ZSB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24uIFRoaXMgbWVh
bnMgdGhlIGV4aXN0ZW5jZS9hYnNlbmNlIG9mIGFuIE5QIGNvbnRhaW5lciBjYW5ub3QgYmUga25v
d24vc3RvcmVkL3JlbWVtYmVyZWQgZXZlbiBpbnRlcm5hbGx5IGJ5IGEgY29uZm9ybWluZyBzeXN0
ZW0uIFRoZSBleGlzdGVuY2UvYWJzZW5jZSBvZiBhbiBOUCBjb250YWluZXIgaXMgYSBtb290IHF1
ZXN0aW9uLiBJdCdzIGEgYml0IGxpa2UgYXNraW5nIGZvciB0aGUgdmFsdWUgb2YgYSB2b2lkIGZ1
bmN0aW9uLiBJdCdzIHRoZXJlLCBpdCBoYXMgYSBuYW1lLCBidXQgbm8gdmFsdWUuDQoNCkltcGxl
bWVudGF0aW9ucyB0aGF0IHJlY2VpdmUgYSA8Z2V0PiBvciA8Z2V0LWNvbmZpZz4gcmVxdWVzdCB0
aGF0IGNvbnRhaW5zIGFuIE5QIGNvbnRhaW5lciB3aWxsIGhhdmUgdG8gZGVjaWRlIHdoZXRoZXIg
dG8gaW5jbHVkZSB0aGUgTlAgY29udGFpbmVyIGluIHRoZSByZXNwb25zZSBvciBub3QuIFNpbmNl
IHRoZSBleGlzdGVuY2Ugb2YgdGhlIE5QIGNvbnRhaW5lciBjYW5ub3QgYmUgcmVhZCBmcm9tIGEg
ZGF0YWJhc2UvZXRjIChpdCBoYXMgemVybyBiaXRzIG9mIGluZm9ybWF0aW9uKSwgdGhlIGltcGxl
bWVudGF0aW9uIHdpbGwgaGF2ZSB0byB1c2Ugc29tZSBvdGhlciB3YXkgdG8gZGV0ZXJtaW5lIHdo
ZXRoZXIgdG8gaW5jbHVkZSBpdCBvciBub3QuDQoNCkluIG9yZGVyIHRvIG1ha2UgdGhlIGxpZmUg
ZWFzaWVyIGZvciBpbXBsZW1lbnRvcnMsIHRoZSBmb2xsb3dpbmcgTUFZIHdhcyBpbnRyb2R1Y2Vk
IGluIHNlYyA3LjUuNzoNCg0KDQogICBBIE5FVENPTkYgc2VydmVyIHRoYXQgcmVwbGllcyB0byBh
IDxnZXQ+IG9yIDxnZXQtY29uZmlnPiByZXF1ZXN0IE1BWQ0KDQogICBjaG9vc2Ugbm90IHRvIHNl
bmQgYSBjb250YWluZXIgZWxlbWVudCBpZiB0aGUgY29udGFpbmVyIG5vZGUgZG9lcyBub3QNCg0K
ICAgaGF2ZSB0aGUgInByZXNlbmNlIiBzdGF0ZW1lbnQgYW5kIG5vIGNoaWxkIG5vZGVzIGV4aXN0
Lg0KDQpTbyB0aGUgTlAgY29udGFpbmVyIGhhcyB0byBiZSBpbmNsdWRlZCBpZiBpdCBoYXMgY2hp
bGRyZW4sIG9yIGVsc2UgdGhlIHN0cnVjdHVyYWwgZnVuY3Rpb24gb2YgdGhlIGNvbnRhaW5lciB3
b3VsZCBiZSBsb3N0LiBJZiB0aGUgTlAgY29udGFpbmVyIGlzIGVtcHR5LCBpdCBtYXkgb3IgbWF5
IG5vdCBiZSBzZW50LiBTaW5jZSBhbiBOUCBjb250YWluZXIgaGFzIHplcm8gYml0cyBvZiBpbmZv
cm1hdGlvbiwgdGhpcyBkZWNpc2lvbiB3b3VsZCBub3QgYmUgYmFzZWQgb24gd2hldGhlciBpdCBo
YXMgYmVlbiBwcmV2aW91c2x5ICJjcmVhdGVkIiBvciAiZGVsZXRlZCIsIGJ1dCBvbiBpbXBsZW1l
bnRhdGlvbiBjb25zaWRlcmF0aW9ucy4gT25lIHBvc3NpYmxlIGFwcHJvYWNoIGlzIHRvIGFsd2F5
cyBpbmNsdWRlIGl0LCBhbm90aGVyIHRvIGFjdHVhbGx5IGNoZWNrIGlmIHRoZXJlIGFyZSBhbnkg
Y2hpbGRyZW4sIGFuZCBvbmx5IHJldHVybiBpdCB0aGVuLg0KDQpFaXRoZXIgd2F5LCBOUCBjb250
YWluZXJzIGFsb25lIGhhdmUgbm8gbWVhbmluZy9pbmZvcm1hdGlvbiwgdGhleSBhcmUgb25seSB0
aGVyZSBmb3Igc3RydWN0dXJlLg0KDQoNCkEgZmFsc2UgbXVzdC1zdG10IGluIGFuIE5QLWNvbnRh
aW5lciBpcyBzdGlsbCBhbiBlcnJvci4NCg0KQ2VydGFpbmx5LiBNdXN0IHN0YXRlbWVudHMgb24g
YW4gTlAgY29udGFpbmVyIGFyZSBhbHdheXMgZXZhbHVhdGVkLCBldmVuIGlmIHRoZSBjb250YWlu
ZXIgaGFzbid0IGJlZW4gImNyZWF0ZWQiIG9yIG1lbnRpb25lZCBieSBhIGNsaWVudCwgYW5kIGV2
ZW4gaWYgaXQgaGFzIG5vIGNoaWxkIGVsZW1lbnRzLg0KDQoNCkFzIExhZGEgaGFzIHBvaW50ZWQg
b3V0IG1hbnkgdGltZXMsIHRoZSB0ZXh0IGFib3V0DQpOUCBjb250YWluZXJzIG5vdCBiZWluZyBw
YXJ0IG9mIHRoZSBkYXRhIG1vZGVsIGlzIGp1c3Qgd3JvbmcuDQoNCkkgdGhpbmsgdGhlIGxlbmd0
aCBvZiB0aGlzIGRpc2N1c3Npb24gaW1wbGllcyB3ZSBzaG91bGQgaW5jbHVkZSB0aGlzIHRvcGlj
IGluIHRoZSB1cGNvbWluZyBZQU5HIEZBUS4NClRoZSBzZXJ2ZXIgc2hvdWxkIG5vdCBlcnJvciBp
biB0aGUgY2FzZXMgTWFoZXNoICYgRWluYXIgc2hvdyAtPiB0aGUgcHJlc2VuY2UvZXhpc3RlbmNl
IG9mIE5QLWNvbnRhaW5lcnMgc2hvdWxkbuKAmXQgcmVhbGx5IGFmZmVjdCBiZWhhdmlvciAoc2lu
Y2UgdGhleSBhcmVu4oCZdCByZWFsbHkgY29uZmlnKS4NCkkgYWdyZWUgd2l0aCB0aGUgYWJvdmUu
DQoNCkJ1dCBJ4oCZbSBub3QgcG9zaXRpdmUgd2hhdCB5b3UgbWVhbiBieSDigJxtYW5hZ2VyIG5l
ZWRzIHRvIGd1YXJk4oCdLiAgRG8geW91IGFncmVlIHRoYXQgdGhlIHNlcnZlciBzaG91bGQgbm90
IGVycm9yIGluIHRob3NlIGNhc2VzIGJlbG93ID8NClRoZSBZQU5HIHRleHQgc2F5cyBhIHNlcnZl
ciBNQVkgZGVsZXRlIGFuIGVtcHR5IE5QIGNvbnRhaW5lci4NClVzaW5nIGRlZmF1bHQtb3BlcmF0
aW9uPW5vbmUgaW1wbGllcyB0aGF0IHRoZSBjbGllbnQgaXMgc3VyZSB0aGUgbm9kZXMgZm9yIG9w
ZXJhdGlvbj1ub25lDQphY3R1YWxseSBleGlzdC4gIEJlY2F1c2Ugb2YgdGhpcyBZQU5HIGRldGFp
bCwgdGhlIGNsaWVudCBjYW5ub3QgYmUgc3VyZSBzbyB1c2luZw0KZGVmYXVsdC1vcGVyYXRpb249
bm9uZSBtYXkgbm90IHdvcmsuDQoNCkkgZGlzYWdyZWUgd2l0aCB0aGlzIGNvbmNsdXNpb24uIEV2
ZW4gdXNpbmcgZGVmYXVsdC1vcGVyYXRpb249bm9uZSB0aGUgdHJhbnNhY3Rpb25zIG11c3QgYmUg
Z3VhcmFudGVlZCB0byB3b3JrIGJ5IGEgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbi4gTlAgY29u
dGFpbmVycyBjYW5ub3QgYmUgY3JlYXRlZC9kZWxldGVkIGluIGEgZGVlcGVyIHNlbnNlIG9mIHRo
ZSB3b3JkIHNpbmNlIHRoZXkgaGF2ZSB6ZXJvIGluZm9ybWF0aW9uIGNvbnRlbnQuIFRoZXkgY2Fu
IG9ubHkgYmUgcmVmZXJyZWQgdG8uIEFueSBtdXN0IHN0YXRlbWVudHMgd2l0aGluIHRoZSBjb250
YWluZXIgbXVzdCBiZSBldmFsdWF0ZWQgcmVnYXJkbGVzcyBvZiB0aGUgY2xpZW50IGV2ZXIgbWVu
dGlvbmluZyB0aGUgY29udGFpbmVyLg0KDQoNCg0KSSBkbyBub3QgYWdyZWUgdGhhdCBkZWZhdWx0
LW9wZXJhdGlvbj1ub25lIGRvZXMgbm90IGFwcGx5IHRvIE5QIGNvbnRhaW5lcnMuDQoNClRoaXMg
aXMgd2h5IGl0IHdhcyBzdWNoIGEgYmFkIGRlY2lzaW9uIHRvIHNwcmVhZCBsaXR0bGUgcGllY2Vz
IG9mIE5FVENPTkYNCmFsbCBvdmVyIHRoZSBZQU5HIFJGQy4gUkZDIDYyNDEgZGVmaW5lcyB0aGUg
J2RlZmF1bHQtb3BlcmF0aW9uJyBsZWFmDQphbmQgaXQgZG9lcyBub3Qgc2F5IGFueXRoaW5nIGFi
b3V0IHNwZWNpYWwgdHJlYXRtZW50IGZvciBOUCBjb250YWluZXJzLg0KDQoNCiAgIG5vbmU6ICBU
aGUgdGFyZ2V0IGRhdGFzdG9yZSBpcyB1bmFmZmVjdGVkIGJ5IHRoZSBjb25maWd1cmF0aW9uDQoN
CiAgICAgICAgICAgIGluIHRoZSA8Y29uZmlnPiBwYXJhbWV0ZXIsIHVubGVzcyBhbmQgdW50aWwg
dGhlIGluY29taW5nDQoNCiAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gZGF0YSB1c2VzIHRoZSAi
b3BlcmF0aW9uIiBhdHRyaWJ1dGUgdG8gcmVxdWVzdA0KDQogICAgICAgICAgICBhIGRpZmZlcmVu
dCBvcGVyYXRpb24uICBJZiB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUgPGNvbmZpZz4NCg0KICAg
ICAgICAgICAgcGFyYW1ldGVyIGNvbnRhaW5zIGRhdGEgZm9yIHdoaWNoIHRoZXJlIGlzIG5vdCBh
DQoNCiAgICAgICAgICAgIGNvcnJlc3BvbmRpbmcgbGV2ZWwgaW4gdGhlIHRhcmdldCBkYXRhc3Rv
cmUsIGFuIDxycGMtZXJyb3I+DQoNCiAgICAgICAgICAgIGlzIHJldHVybmVkIHdpdGggYW4gPGVy
cm9yLXRhZz4gdmFsdWUgb2YgZGF0YS1taXNzaW5nLg0KDQogICAgICAgICAgICBVc2luZyAibm9u
ZSIgYWxsb3dzIG9wZXJhdGlvbnMgbGlrZSAiZGVsZXRlIiB0byBhdm9pZA0KDQogICAgICAgICAg
ICB1bmludGVudGlvbmFsbHkgY3JlYXRpbmcgdGhlIHBhcmVudCBoaWVyYXJjaHkgb2YgdGhlIGVs
ZW1lbnQNCg0KICAgICAgICAgICAgdG8gYmUgZGVsZXRlZC4NCg0KDQovamFuDQoNCg0KQW5keQ0K
DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCCB2EAUS70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0
IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6
MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg
TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD
b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj
b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KGYpIHNob3VsZCBiZSBhY2NlcHRlZCB3
aXRob3V0IGFuIGVycm9yIElNTy4mbmJzcDsmbmJzcDsgVGhlIHByZXNlbmNlL2V4aXN0ZW5jZSAo
b3Igbm90KSBvZiBhbiBOUC1jb250YWluZXIgc2hvdWxkIG5vdCBhZmZlY3QgdGhlIGJlaGF2aW9y
LiZuYnNwOyZuYnNwOyBNYXliZSB0aGF0IGlzbuKAmXQgc3BlbGxlZA0KIG91dCBpbiB0aGUgUkZD
cyBidXQgSSBoYXZlIG15IGRvdWJ0cyBtYW55IGltcGxlbWVudGF0aW9ucyB3b3VsZCByZWplY3Qg
KGYpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PiBYaWFuZyBMaSBbbWFpbHRvOnhpYW5nbGlAc2VndWVzb2Z0LmNvbV0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBGcmlkYXksIEp1bHkgMTUsIDIwMTYgMTQ6MTE8YnI+DQo8Yj5Ubzo8L2I+IEphbiBMaW5k
YmxhZDsgQW5keSBCaWVybWFuOyBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKTxicj4NCjxiPkNj
OjwvYj4gTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFdoYXQgc2hv
dWxkIGEgc2VydmVyIHJlc3BvbnNlIGJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzE1LzIwMTYgMTo0NiBBTSwgSmFuIExpbmRibGFk
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu
IG9yZGVyIHRvIHJlYWNoIHJvdWdoIGNvbnNlbnN1cyBvbiB0aGUgaW50ZXJwcmV0YXRpb24gb2Yg
dGhlIGRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgc2VxdWVuY2UsIEkgdGhpbmsgd2UgbmVlZCB0byBz
dGFydCB3aXRoIGNvbWluZyB0byBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgTlAgY29u
dGFpbmVycyBhcmUuIENhbiBOUCBjb250YWluZXJzIGJlICZxdW90O2NyZWF0ZWQmcXVvdDsgYW5k
ICZxdW90O2RlbGV0ZWQmcXVvdDsganVzdA0KIGxpa2UgUCBjb250YWluZXJzPyA8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUncyBhIHRlc3QgdG8gc2Vl
IGlmIHRoZXJlIGlzIGFueSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGJlaGF2aW9yIG9mIHAgYW5k
IG5wIGNvbnRhaW5lcnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPmxpc3QgdCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGtleSBhOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBsZWFmIGEgeyB0
eXBlIHVpbnQzMjsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjb250YWluZXIgbnAgezxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IG11c3QgJnF1b3Q7Li4vYSAmZ3Q7IDEwJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGNv
bnRhaW5lciBwIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcmVzZW5jZSAmcXVvdDsuLi4mcXVv
dDs7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbXVzdCAmcXVvdDsuLi9hICZndDsgMjAmcXVvdDs7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlIGNvbmZpZyBpcyBpbml0aWFsbHkgZW1wdHkuIE5vdywgd291bGQgaXQgYmUgcG9z
c2libGUgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YSkgY3JlYXRlIGFuIGluc3RhbmNlIHdpdGggYSA9IDUgaWYgdGhlcmUgaXMgbm8gbWVu
dGlvbiBvZiBucCBhbmQgcCBpbiB0aGUgZWRpdC1jb25maWc/PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iKSBjcmVhdGUgYW4gaW5zdGFuY2Ugd2l0
aCBhID0gNSBpZiBucCAoYnV0IG5vdCBwKSBpcyAmcXVvdDtjcmVhdGVkJnF1b3Q7IGluIHRoZSBl
ZGl0LWNvbmZpZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPmMpIGNyZWF0ZSBhbiBpbnN0YW5jZSB3aXRoIGEgPSAxNSBpZiB0aGVyZSBpcyBubyBt
ZW50aW9uIG9mIG5wIGFuZCBwIGluIHRoZSBlZGl0LWNvbmZpZz88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmQpIGNyZWF0ZSBhbiBpbnN0YW5jZSB3
aXRoIGEgPSAxNSBpZiBwIGlzIGNyZWF0ZWQgaW4gdGhlIGVkaXQtY29uZmlnPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5NeSBvd24gYW5zd2VyIGlzIHRoYXQgb25seSBvcGVyYXRpb24gYyBpcyBhbGxvd2VkLiAmcXVv
dDtjcmVhdGlvbiZxdW90OyBvZiBhbiBOUCBjb250YWluZXIgaXMgaXJyZWxldmFudCwgd2hpbGUg
Y3JlYXRpb24gb2YgYSBQIGNvbnRhaW5lciBtYWtlcyBhIGRpZmZlcmVuY2UuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClll
cyBJIGFncmVlIDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuIE5QIGNvbnRhaW5lciBpcyBzaW1wbHkgYSBzdHJ1Y3R1
cmFsIGVsZW1lbnQsIGFuZCBkb2VzIG5vdCBuZWVkIHRvIGJlICZxdW90O2NyZWF0ZWQmcXVvdDsg
dG8gZXhpc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCkkgdW5kZXJzdGFuZCB0aGUgJnF1b3Q7ZG9lcyBub3QgbmVlZCB0byBiZSAnY3JlYXRlZCcg
dG8gZXhpc3QmcXVvdDsgcGFydC4gVGhlIGNvbmZ1c2lvbiBhcmlzZXMgYWJvdXQgd2hhdCBpcyBh
IGNvbXBsaWFudA0KPGJyPg0KaW1wbGVtZW50YXRpb24gd2hlbiBhIGNsaWVudCBkb2VzIHdhbnQg
dG8gY3JlYXRlIGl0IGV4cGxpY2l0bHkgZm9yIHdoYXRldmVyIHJlYXNvbi4gVXNpbmcgeW91ciBl
eGFtcGxlDQo8YnI+DQooYSB2ZXJ5IGdvb2QgZXhhbXBsZSwgYnkgdGhlIHdheSk8YnI+DQo8YnI+
DQplKSBjcmVhdGUgd2l0aCBhID0gMTUsJm5ic3A7IGFuZCBhbHNvIGNyZWF0ZSBucCZuYnNwOyBl
eHBsaWNpdGx5PGJyPg0KPGJyPg0KYW5kIHRoZW4gZm9sbG93cyB1cCB3aXRoIGFuIGFkZGl0aW9u
YWwgZWRpdC1jb25maWc8YnI+DQpmKSZuYnNwOyBtZXJnZSB3aXRoIGEgPSAxNSwgYW5kIGNyZWF0
ZSBucCBleHBsaWNpdGx5IGFnYWluIDxicj4NCjxicj4NCjxicj4NCnNob3VsZCBhIGNvbXBsaWFu
dCBzZXJ2ZXIgcmVqZWN0IGYpIG9yIG5vdD88YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgZW1wdHkgTlAgY29udGFpbmVycyBN
QVkgbm90IGJlIHJlcG9ydGVkIHNpbmNlIHRoZXkgYXJlIG1lYW5pbmdsZXNzIGFueXdheS48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIDxicj4N
Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PklmIG11c3Qgc3RhdGVtZW50cyBpbiBucCBjb250YWluZXJzIGFyZSBpbiBlZmZlY3QgZXZlbiBp
ZiB0aGUgY2xpZW50IGlzbid0IGV4cGxpY2l0bHkgJnF1b3Q7Y3JlYXRpbmcmcXVvdDsgb3IgbWVu
dGlvbmluZyB0aGUgY29udGFpbmVyLCB0aGVuIEkgZmluZCBpdCBoYXJkIHRvIHVuZGVyc3RhbmQg
dGhlIHZpZXdwb2ludCB0aGF0ICZxdW90O2NyZWF0aW9uJnF1b3Q7IG9mIE5QIGNvbnRhaW5lcnMg
bWFrZXMgYW55IGRpZmZlcmVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGJyPg0KSXQgZG9lc24ndC4gV2hhdCBJIGFtIHRyeWluZyB0byBmaWd1cmUg
b3V0IGlzJm5ic3A7IGhvdyBhIGNvbXBsaWFudCBzZXJ2ZXIgaW1wbGVtZW50YXRpb248YnI+DQom
bmJzcDtzaG91bGQgaGFuZGxlJm5ic3A7IHRoZSAmcXVvdDtvcGVyYXRpb24mcXVvdDsmbmJzcDsg
b24gYSBOUCBjb250YWluZXIgbm9kZSBpbiBhICZsdDtlZGl0LWNvbmZpZyZndDsuJm5ic3A7IDxi
cj4NCjxicj4NCi1YaWFuZzxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9qYW48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N
CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2NvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgSSBkb27igJl0IHJlYWxseSBzZWUgTlAtY29udGFp
bmVycyBhcyDigJxjb25maWfigJ0uJm5ic3A7IFRoZXkgYXJlIGp1c3Qgc3RydWN0dXJlIGFuZCBm
aWx0ZXJlZCBvdXQgd2hlbiBlbXB0eS4mbmJzcDsgSSBkb27igJl0IHJlYWxseSBzZWUgdGhpcw0K
IGFzIHRoZSBzZXJ2ZXIg4oCcZGVsZXRpbmfigJ0gdGhvc2UgY29udGFpbmVycy4mbmJzcDsgSXQg
anVzdCBzdXBwcmVzc2VzIHRoZW0gaW4gJmx0O2dldC1jb25maWcmZ3Q7IG91dHB1dC4gJm5ic3A7
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5QbGVhc2Ugc2hvdyBt
ZSB0aGUgUkZDIHRleHQgdGhhdCBzYXlzIHRoZSBzZXJ2ZXIgY2FuIGZpbHRlciBvdXQgTlAgY29u
dGFpbmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+QWxsIGNvbmZpZz10cnVl
IGRhdGEgbm9kZXMgYXJlIGNvbmZpZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQiPkluIGEgdmVyeSB0ZWNobmljYWwgc2Vuc2UsIEkgc3VwcG9z
ZSB0aGUgYWJvdmUgc3RhdGVtZW50IGlzIGNvcnJlY3QuIEFuIE5QIGNvbnRhaW5lciBpcyBvZiBj
b3Vyc2UgY29uZmlnIHRydWUgaWYgaXQgc2l0cyBpbiB0aGUgY29uZmlnIHRydWUgcGFydCBvZiB0
aGUgdHJlZS4gQXQgdGhlIHNhbWUgdGltZSBJIGFncmVlIHdpdGggSmFuc29uJ3MgdmlldyB0aGF0
DQogTlAgY29udGFpbmVycyBhcmUganVzdCBzdHJ1Y3R1cmUsIHNvIHRoZSBxdWVzdGlvbiBvZiB0
aGVpciAmcXVvdDtleGlzdGVuY2UmcXVvdDsgaXMgbW9vdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PkhlcmUncyB3aGF0IFJGQyA2MDIwLCBzZWMgNy41IHNheXMgb24gdGhlIHRvcGljOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBZQU5HIHN1cHBvcnRzIHR3byBzdHlsZXMg
b2YgY29udGFpbmVycywgdGhvc2UgdGhhdCBleGlzdCBvbmx5IGZvcjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyBvcmdhbml6aW5nIHRoZSBoaWVyYXJjaHkgb2YgZGF0YSBub2Rl
cywgYW5kIHRob3NlIHdob3NlIHByZXNlbmNlIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IHRoZSBjb25maWd1cmF0aW9uIGhhcyBhbiBleHBsaWNpdCBtZWFuaW5nLjxvOnA+
PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQiPlNvIE5QIGNvbnRhaW5lcnMgJnF1b3Q7ZXhpc3Qgb25seSBmb3Igb3JnYW5pemluZyB0
aGUgaGllcmFyY2h5JnF1b3Q7IHdoaWxlIGEgUCBjb250YWluZXIgJnF1b3Q7aGFzIGFuIGV4cGxp
Y2l0IG1lYW5pbmcmcXVvdDsuIEkgZ3Vlc3MgdGhpcyBpbXBsaWVzIE5QIGNvbnRhaW5lcnMgaGF2
aW5nIG5vIG1lYW5pbmcuIEZ1cnRoZXIgZG93biBpbiA3LjUuMSwgcmUgUCBjb250YWluZXJzLCBp
dCBpcw0KIG5vdGVkIHRoYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IEluIHRoZSBzZWNvbmQgc3R5bGUsIHRoZSBwcmVzZW5jZSBvZiB0aGUgY29udGFpbmVyIGl0c2Vs
ZiBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9uIGRh
dGEsIHJlcHJlc2VudGluZyBhIHNpbmdsZSBiaXQgb2YgY29uZmlndXJhdGlvbiBkYXRhLjxvOnA+
PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlIGNvbnRhaW5lciBhY3Rz
IGFzIGJvdGggYSBjb25maWd1cmF0aW9uIGtub2IgYW5kIGEgbWVhbnMgb2Y8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb3JnYW5pemluZyByZWxhdGVkIGNvbmZpZ3VyYXRpb24u
Jm5ic3A7IFRoZXNlIGNvbnRhaW5lcnMgYXJlIGV4cGxpY2l0bHk8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsgY3JlYXRlZCBhbmQgZGVsZXRlZC48bzpwPjwvbzpwPjwvcHJlPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PkJhc2VkIG9uIHRoZXNlIGZyYWdtZW50cywgSSBjb25jbHVkZSB0aGF0IE5QIGNvbnRhaW5lcnMg
aGF2ZSB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24uIFRoaXMgbWVhbnMgdGhlIGV4aXN0ZW5jZS9h
YnNlbmNlIG9mIGFuIE5QIGNvbnRhaW5lciBjYW5ub3QgYmUga25vd24vc3RvcmVkL3JlbWVtYmVy
ZWQgZXZlbiBpbnRlcm5hbGx5IGJ5IGEgY29uZm9ybWluZw0KIHN5c3RlbS4gVGhlIGV4aXN0ZW5j
ZS9hYnNlbmNlIG9mIGFuIE5QIGNvbnRhaW5lciBpcyBhIG1vb3QgcXVlc3Rpb24uIEl0J3MgYSBi
aXQgbGlrZSBhc2tpbmcgZm9yIHRoZSB2YWx1ZSBvZiBhIHZvaWQgZnVuY3Rpb24uIEl0J3MgdGhl
cmUsIGl0IGhhcyBhIG5hbWUsIGJ1dCBubyB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPkltcGxlbWVu
dGF0aW9ucyB0aGF0IHJlY2VpdmUgYSAmbHQ7Z2V0Jmd0OyBvciAmbHQ7Z2V0LWNvbmZpZyZndDsg
cmVxdWVzdCB0aGF0IGNvbnRhaW5zIGFuIE5QIGNvbnRhaW5lciB3aWxsIGhhdmUgdG8gZGVjaWRl
IHdoZXRoZXIgdG8gaW5jbHVkZSB0aGUgTlAgY29udGFpbmVyIGluIHRoZSByZXNwb25zZSBvciBu
b3QuIFNpbmNlIHRoZSBleGlzdGVuY2Ugb2YgdGhlIE5QIGNvbnRhaW5lcg0KIGNhbm5vdCBiZSBy
ZWFkIGZyb20gYSBkYXRhYmFzZS9ldGMgKGl0IGhhcyB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24p
LCB0aGUgaW1wbGVtZW50YXRpb24gd2lsbCBoYXZlIHRvIHVzZSBzb21lIG90aGVyIHdheSB0byBk
ZXRlcm1pbmUgd2hldGhlciB0byBpbmNsdWRlIGl0IG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPklu
IG9yZGVyIHRvIG1ha2UgdGhlIGxpZmUgZWFzaWVyIGZvciBpbXBsZW1lbnRvcnMsIHRoZSBmb2xs
b3dpbmcgTUFZIHdhcyBpbnRyb2R1Y2VkIGluIHNlYyA3LjUuNzo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHByZT4mbmJzcDsmbmJzcDsgQSBORVRDT05GIHNlcnZlciB0aGF0IHJlcGxpZXMgdG8gYSAm
bHQ7Z2V0Jmd0OyBvciAmbHQ7Z2V0LWNvbmZpZyZndDsgcmVxdWVzdCBNQVk8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2hvb3NlIG5vdCB0byBzZW5kIGEgY29udGFpbmVyIGVs
ZW1lbnQgaWYgdGhlIGNvbnRhaW5lciBub2RlIGRvZXMgbm90PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IGhhdmUgdGhlICZxdW90O3ByZXNlbmNlJnF1b3Q7IHN0YXRlbWVudCBh
bmQgbm8gY2hpbGQgbm9kZXMgZXhpc3QuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+U28gdGhlIE5QIGNvbnRhaW5lciBo
YXMgdG8gYmUgaW5jbHVkZWQgaWYgaXQgaGFzIGNoaWxkcmVuLCBvciBlbHNlIHRoZSBzdHJ1Y3R1
cmFsIGZ1bmN0aW9uIG9mIHRoZSBjb250YWluZXIgd291bGQgYmUgbG9zdC4gSWYgdGhlIE5QIGNv
bnRhaW5lciBpcyBlbXB0eSwgaXQgbWF5IG9yIG1heSBub3QgYmUgc2VudC4gU2luY2UgYW4gTlAg
Y29udGFpbmVyIGhhcw0KIHplcm8gYml0cyBvZiBpbmZvcm1hdGlvbiwgdGhpcyBkZWNpc2lvbiB3
b3VsZCBub3QgYmUgYmFzZWQgb24gd2hldGhlciBpdCBoYXMgYmVlbiBwcmV2aW91c2x5ICZxdW90
O2NyZWF0ZWQmcXVvdDsgb3IgJnF1b3Q7ZGVsZXRlZCZxdW90OywgYnV0IG9uIGltcGxlbWVudGF0
aW9uIGNvbnNpZGVyYXRpb25zLiBPbmUgcG9zc2libGUgYXBwcm9hY2ggaXMgdG8gYWx3YXlzIGlu
Y2x1ZGUgaXQsIGFub3RoZXIgdG8gYWN0dWFsbHkgY2hlY2sgaWYgdGhlcmUgYXJlIGFueSBjaGls
ZHJlbiwgYW5kDQogb25seSByZXR1cm4gaXQgdGhlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPkVpdGhlciB3
YXksIE5QIGNvbnRhaW5lcnMgYWxvbmUgaGF2ZSBubyBtZWFuaW5nL2luZm9ybWF0aW9uLCB0aGV5
IGFyZSBvbmx5IHRoZXJlIGZvciBzdHJ1Y3R1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
Ij5BIGZhbHNlIG11c3Qtc3RtdCBpbiBhbiBOUC1jb250YWluZXIgaXMgc3RpbGwgYW4gZXJyb3Iu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5DZXJ0YWlubHkuIE11c3Qg
c3RhdGVtZW50cyBvbiBhbiBOUCBjb250YWluZXIgYXJlIGFsd2F5cyBldmFsdWF0ZWQsIGV2ZW4g
aWYgdGhlIGNvbnRhaW5lciBoYXNuJ3QgYmVlbiAmcXVvdDtjcmVhdGVkJnF1b3Q7IG9yIG1lbnRp
b25lZCBieSBhIGNsaWVudCwgYW5kIGV2ZW4gaWYgaXQgaGFzIG5vIGNoaWxkIGVsZW1lbnRzLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+QXMgTGFkYSBoYXMgcG9pbnRlZCBvdXQgbWFueSB0
aW1lcywgdGhlIHRleHQgYWJvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+TlAg
Y29udGFpbmVycyBub3QgYmVpbmcgcGFydCBvZiB0aGUgZGF0YSBtb2RlbCBpcyBqdXN0IHdyb25n
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SSB0aGluayB0aGUgbGVu
Z3RoIG9mIHRoaXMgZGlzY3Vzc2lvbiBpbXBsaWVzIHdlIHNob3VsZCBpbmNsdWRlIHRoaXMgdG9w
aWMgaW4gdGhlIHVwY29taW5nIFlBTkcgRkFRLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx
RjQ5N0QiPlRoZSBzZXJ2ZXIgc2hvdWxkIG5vdCBlcnJvciBpbiB0aGUgY2FzZXMgTWFoZXNoICZh
bXA7IEVpbmFyIHNob3cgLSZndDsgdGhlIHByZXNlbmNlL2V4aXN0ZW5jZSBvZiBOUC1jb250YWlu
ZXJzIHNob3VsZG7igJl0IHJlYWxseSBhZmZlY3QgYmVoYXZpb3INCiAoc2luY2UgdGhleSBhcmVu
4oCZdCByZWFsbHkgY29uZmlnKS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SSBhZ3JlZSB3aXRoIHRoZSBh
Ym92ZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkJ1dCBJ4oCZbSBub3Qg
cG9zaXRpdmUgd2hhdCB5b3UgbWVhbiBieSDigJxtYW5hZ2VyIG5lZWRzIHRvIGd1YXJk4oCdLiZu
YnNwOyBEbyB5b3UgYWdyZWUgdGhhdCB0aGUgc2VydmVyIHNob3VsZCBub3QgZXJyb3IgaW4gdGhv
c2UgY2FzZXMgYmVsb3cNCiA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdCI+VGhlIFlBTkcgdGV4dCBzYXlzIGEgc2VydmVyIE1BWSBkZWxldGUg
YW4gZW1wdHkgTlAgY29udGFpbmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5V
c2luZyBkZWZhdWx0LW9wZXJhdGlvbj1ub25lIGltcGxpZXMgdGhhdCB0aGUgY2xpZW50IGlzIHN1
cmUgdGhlIG5vZGVzIGZvciBvcGVyYXRpb249bm9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0Ij5hY3R1YWxseSBleGlzdC4mbmJzcDsgQmVjYXVzZSBvZiB0aGlzIFlBTkcgZGV0YWls
LCB0aGUgY2xpZW50IGNhbm5vdCBiZSBzdXJlIHNvIHVzaW5nPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQiPmRlZmF1bHQtb3BlcmF0aW9uPW5vbmUgbWF5IG5vdCB3b3JrLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SSBkaXNhZ3JlZSB3aXRoIHRoaXMgY29u
Y2x1c2lvbi4gRXZlbiB1c2luZyBkZWZhdWx0LW9wZXJhdGlvbj1ub25lIHRoZSB0cmFuc2FjdGlv
bnMgbXVzdCBiZSBndWFyYW50ZWVkIHRvIHdvcmsgYnkgYSBjb25mb3JtaW5nIGltcGxlbWVudGF0
aW9uLiBOUCBjb250YWluZXJzIGNhbm5vdCBiZSBjcmVhdGVkL2RlbGV0ZWQgaW4gYSBkZWVwZXIg
c2Vuc2Ugb2YgdGhlDQogd29yZCBzaW5jZSB0aGV5IGhhdmUgemVybyBpbmZvcm1hdGlvbiBjb250
ZW50LiBUaGV5IGNhbiBvbmx5IGJlIHJlZmVycmVkIHRvLiBBbnkgbXVzdCBzdGF0ZW1lbnRzIHdp
dGhpbiB0aGUgY29udGFpbmVyIG11c3QgYmUgZXZhbHVhdGVkIHJlZ2FyZGxlc3Mgb2YgdGhlIGNs
aWVudCBldmVyIG1lbnRpb25pbmcgdGhlIGNvbnRhaW5lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdCI+SSBkbyBub3QgYWdyZWUgdGhhdCBkZWZhdWx0LW9wZXJhdGlvbj1ub25lIGRvZXMgbm90
IGFwcGx5IHRvIE5QIGNvbnRhaW5lcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5UaGlzIGlzIHdoeSBpdCB3
YXMgc3VjaCBhIGJhZCBkZWNpc2lvbiB0byBzcHJlYWQgbGl0dGxlIHBpZWNlcyBvZiBORVRDT05G
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPmFsbCBvdmVyIHRoZSBZQU5HIFJGQy4g
UkZDIDYyNDEgZGVmaW5lcyB0aGUgJ2RlZmF1bHQtb3BlcmF0aW9uJyBsZWFmPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQiPmFuZCBpdCBkb2VzIG5vdCBzYXkgYW55dGhpbmcgYWJvdXQg
c3BlY2lhbCB0cmVhdG1lbnQgZm9yIE5QIGNvbnRhaW5lcnMuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwcmUgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+
Jm5ic3A7Jm5ic3A7IG5vbmU6Jm5ic3A7IFRoZSB0YXJnZXQgZGF0YXN0b3JlIGlzIHVuYWZmZWN0
ZWQgYnkgdGhlIGNvbmZpZ3VyYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
aW4gdGhlICZsdDtjb25maWcmZ3Q7IHBhcmFtZXRlciwgdW5sZXNzIGFuZCB1bnRpbCB0aGUgaW5j
b21pbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmlndXJhdGlvbiBkYXRh
IHVzZXMgdGhlICZxdW90O29wZXJhdGlvbiZxdW90OyBhdHRyaWJ1dGUgdG8gcmVxdWVzdDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDthIGRpZmZlcmVudCBvcGVyYXRpb24uJm5ic3A7
IElmIHRoZSBjb25maWd1cmF0aW9uIGluIHRoZSAmbHQ7Y29uZmlnJmd0OzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIgY29udGFpbnMgZGF0YSBmb3Igd2hpY2ggdGhl
cmUgaXMgbm90IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29ycmVzcG9uZGlu
ZyBsZXZlbCBpbiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSwgYW4gJmx0O3JwYy1lcnJvciZndDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgcmV0dXJuZWQgd2l0aCBhbiAmbHQ7ZXJy
b3ItdGFnJmd0OyB2YWx1ZSBvZiBkYXRhLW1pc3NpbmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IFVzaW5nICZxdW90O25vbmUmcXVvdDsgYWxsb3dzIG9wZXJhdGlvbnMgbGlrZSAm
cXVvdDtkZWxldGUmcXVvdDsgdG8gYXZvaWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdW5pbnRlbnRpb25hbGx5IGNyZWF0aW5nIHRoZSBwYXJlbnQgaGllcmFyY2h5IG9mIHRoZSBl
bGVtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGJlIGRlbGV0ZWQuPG86
cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Izg4ODg4OCI+L2phbjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2NvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A125E53CE190A749957C19483DC79F9F5CCCB2EAUS70TWXCHMBA11z_--


From nobody Fri Jul 15 11:48:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1294512D197 for ; Fri, 15 Jul 2016 11:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8A8Zs-7hXKtG for ; Fri, 15 Jul 2016 11:48:08 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C736C12D196 for ; Fri, 15 Jul 2016 11:48:07 -0700 (PDT)
Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 269CDF678D795; Fri, 15 Jul 2016 18:48:04 +0000 (GMT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6FIm5wA006243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 18:48:05 GMT
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u6FIm5BR031638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Jul 2016 18:48:05 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 15 Jul 2016 14:48:05 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Mahesh Jethanandani 
Thread-Topic: [Netconf]  in a server that supports both writable-running and candidate
Thread-Index: AdHeAl/GLPvbP2zwTVylVCsJWBbO+AAKYmOAAAeySJD//+H2gP/+5Qxg
Date: Fri, 15 Jul 2016 18:48:04 +0000
Message-ID: 
References:  <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com>  <40DE01C9-4528-493A-A0C6-08AA4648D900@gmail.com>
In-Reply-To: <40DE01C9-4528-493A-A0C6-08AA4648D900@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCCB3B2US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 18:48:10 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCCB3B2US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTWFoZXNoLA0KDQrigJxUeXBpY2FsIHRyYW5zYWN0aW9u4oCdIHdpdGggd2hhdCBOQyBjbGll
bnQgYW5kIHdoYXQgTkMgc2VydmVyID8NCg0KRGlkIHRoZSBOQyBzZXJ2ZXIgYWR2ZXJ0aXNlIGJv
dGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlIGNhcGFiaWxpdGllcyA/DQoNCklmIGEg
c2VydmVyIG9ubHkgYWR2ZXJ0aXNlcyBjYW5kaWRhdGUgKGFuZCBub3Qgd3JpdGFibGUtcnVubmlu
ZykgdGhlbiBJ4oCZZCBvbmx5IGV4cGVjdCB0aGUgY2xpZW50IHRvIGV2ZXIgbG9jayB0aGUgY2Fu
ZGlkYXRlLg0KDQpKYXNvbg0KDQpGcm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpl
dGhhbmFuZGFuaUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAxNCwgMjAxNiAxNzo1
Mw0KVG86IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpDQpDYzogTmV0Y29uZg0KU3ViamVjdDog
UmU6IFtOZXRjb25mXSA8bG9jaz4gaW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoIHdyaXRh
YmxlLXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZQ0KDQpKYXNvbiwNCg0KT24gSnVsIDE0LCAyMDE2LCBh
dCAxOjM0IFBNLCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSA8amFzb24uc3Rlcm5lQG5va2lh
LmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+IHdyb3RlOg0KDQpIaSBNYWhlc2gs
DQoNCknigJltIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIGZpcnN0IHN0YXRlbWVudC4gIENh
biB5b3UgZXhwbGFpbiBmdXJ0aGVyID8gIEFyZSB5b3Ugc2F5aW5nIHRoYXQgb24gYSBzeXN0ZW0g
dGhhdCBzdXBwb3J0cyBib3RoIHdyaXRhYmxlLXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZSB5b3UgdGhp
bmsgY2xpZW50cyBtYXkganVzdCB0YWtlIHRoZSBsb2NrIG9uIHRoZSBjYW5kaWRhdGUsIGRvIHRo
ZWlyIHVwZGF0ZWQsIGNvbW1pdCBhbmQgdGhlbiByZWxlYXNlIHRoZSBsb2NrID8gICBJIHRoaW5r
IHRoYXQgaXMgcmVhc29uYWJsZS9wb3NzaWJsZS4NCg0KV2hhdCBJIHdhcyBzdGF0aW5nIHdhcyBh
IHN0YXRlbWVudCBvZiBmYWN0LiBIZXJlIGlzIGEgdHlwaWNhbCB0cmFuc2FjdGlvbiB0aGF0IEkg
c2VlLiBOb3RpY2UsIG5vIGVmZm9ydCB0byBsb2NrIHRoZSBydW5uaW5nIGNvbmZpZ3VyYXRpb24u
DQoNCjxycGMgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIN
CiAgICAgbWVzc2FnZS1pZD0iMiI+DQogIDxsb2NrPg0KICAgIDx0YXJnZXQ+DQogICAgICA8Y2Fu
ZGlkYXRlLz4NCiAgICA8L3RhcmdldD4NCiAgPC9sb2NrPg0KPC9ycGM+DQoNCjxycGMtcmVwbHkg
bWVzc2FnZS1pZD3igJwyIg0KICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpu
czpuZXRjb25mOmJhc2U6MS4wIj4NCiAgPG9rLz4NCjwvcnBjLXJlcGx5Pg0KDQo8cnBjIHhtbG5z
PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiDQogICAgIG1lc3NhZ2Ut
aWQ9IjMiPg0KICA8ZWRpdC1jb25maWcgeG1sbnM6bmM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6
bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgPHRhcmdldD4NCiAgICAgIDxjYW5kaWRhdGUvPg0KICAg
IDwvdGFyZ2V0Pg0KICAgIDx0ZXN0LW9wdGlvbj50ZXN0LXRoZW4tc2V0PC90ZXN0LW9wdGlvbj4N
CiAgICA8ZXJyb3Itb3B0aW9uPnJvbGxiYWNrLW9uLWVycm9yPC9lcnJvci1vcHRpb24+DQogICAg
PGNvbmZpZz4NCiAgICAgIOKApiBjb25maWcgc3R1ZmYNCiAgICA8L2NvbmZpZz4NCiAgPC9lZGl0
LWNvbmZpZz4NCjwvcnBjPg0KDQo8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjMiDQogICAgICAgICAg
IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KICA8b2sv
Pg0KPC9ycGMtcmVwbHk+DQoNCjxycGMgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0
Y29uZjpiYXNlOjEuMCINCiAgICAgbWVzc2FnZS1pZD0iNCI+DQogIDxjb21taXQ+DQogICAgPGNv
bmZpcm1lZC8+DQogIDwvY29tbWl0Pg0KPC9ycGM+DQoNCjxycGMtcmVwbHkgbWVzc2FnZS1pZD0i
NCINCiAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNl
OjEuMCI+DQogIDxvay8+DQo8L3JwYy1yZXBseT4NCg0KPHJwYyB4bWxucz0idXJuOmlldGY6cGFy
YW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIg0KICAgICBtZXNzYWdlLWlkPSI1Ij4NCiAgPGNv
bW1pdC8+DQo8L3JwYz4NCg0KPHJwYy1yZXBseSBtZXNzYWdlLWlkPSI1Ig0KICAgICAgICAgICB4
bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgPG9rLz4N
CjwvcnBjLXJlcGx5Pg0KDQo8cnBjIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv
bmY6YmFzZToxLjAiDQogICAgIG1lc3NhZ2UtaWQ9IjYiPg0KICA8dW5sb2NrPg0KICAgIDx0YXJn
ZXQ+DQogICAgICA8Y2FuZGlkYXRlLz4NCiAgICA8L3RhcmdldD4NCiAgPC91bmxvY2s+DQo8L3Jw
Yz4NCg0KPHJwYy1yZXBseSBtZXNzYWdlLWlkPSI2Ig0KICAgICAgICAgICB4bWxucz0idXJuOmll
dGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgPG9rLz4NCjwvcnBjLXJlcGx5
Pg0KDQo8cnBjIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAi
DQogICAgIG1lc3NhZ2UtaWQ9IjciPg0KICA8Y2xvc2Utc2Vzc2lvbi8+DQo8L3JwYz4NCg0KDQoN
CkFzIGZvciBwcmV2ZW50aW5nIG90aGVyIG1nbW50LiBpbnRlcmZhY2VzIGZyb20gaW50ZXJmZXJp
bmcgLT4gSSB0aGluayBSRkM2MjQxIGlzIHJlYXNvbmFibHkgY2xlYXIgdGhhdCBzaG91bGQgYmUg
cHJldmVudGVkOg0KDQpBZGRpdGlvbmFsbHksIHRoZSBzeXN0ZW0NCiAgICAgIHdpbGwgZW5zdXJl
IHRoYXQgdGhlc2UgbG9ja2VkIGNvbmZpZ3VyYXRpb24gcmVzb3VyY2VzIHdpbGwgbm90IGJlDQog
ICAgICBtb2RpZmllZCBieSBvdGhlciBub24tTkVUQ09ORiBtYW5hZ2VtZW50IG9wZXJhdGlvbnMg
c3VjaCBhcyBTTk1QDQogICAgICBhbmQgQ0xJLg0KDQpJIGFncmVlIHdpdGggdGhlIGdlbmVyYWwg
d29ya2Zsb3cgYnV0IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZSBjbGllbnQgc2hvdWxkIGV4
cGxpY2l0bHkgZ2V0IGJvdGggbG9ja3MsIG9yIHdoZXRoZXIgdGhlIHNlcnZlciBzaWRlIHNob3Vs
ZCBpbXBsaWNpdGx5IHRha2UgYm90aCBsb2NrcyAoaS5lLiBwcmV2ZW50IHNlcGFyYXRlIG1vZGlm
aWNhdGlvbnMvbG9jayBvZiB0aGUgb3RoZXIgRFMpLiAgSXQgaXNu4oCZdCBvYnZpb3VzIGJ1dCBJ
IGxlYW4gdG93YXJkcyB0aGUgc2VydmVyIHNpZGUgaGFuZGxpbmcgdGhpcyBzaXR1YXRpb24gKGVz
cGVjaWFsbHkgc2luY2UgdGhlIGNvbWJpbmF0aW9uIG9mIHdyaXRlYWJsZS1ydW5uaW5nIGFuZCBj
YW5kaWRhdGUgc3VwcG9ydCBpcyBzb21ld2hhdCByYXJlKS4NCg0KSmFzb24NCg0KRnJvbTogTWFo
ZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KU2VudDog
VGh1cnNkYXksIEp1bHkgMTQsIDIwMTYgMTY6MDENClRvOiBTdGVybmUsIEphc29uIChOb2tpYSAt
IENBKQ0KQ2M6IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gPGxvY2s+IGluIGEgc2Vy
dmVyIHRoYXQgc3VwcG9ydHMgYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUNCg0K
SSBzZWUgY2xpZW50cyBhY3F1aXJpbmcgbG9jayBvbiB0aGUgY2FuZGlkYXRlIGNvbmZpZyBidXQg
bm90IG9uIHJ1bm5pbmcuIFlvdSBhcmUgcmlnaHQgdGhhdCBpdCBkb2VzIG5vdCBwcmV2ZW50LCBz
YXkgUkVTVENPTkYgb3IgZXZlbiBDTEkgZnJvbSB1cGRhdGluZyB0aGUgcnVubmluZy1jb25maWcg
ZGlyZWN0bHkuDQoNCkEgd29ya2Zsb3cgZm9yIHdoYXQgc2hvdWxkIGJlIGhhcHBlbmluZyBpczoN
Cg0KLSBhY3F1aXJlIGxvY2sgb24gY2FuZGlkYXRlIGFuZCBydW5uaW5nIChjYW4gY3JlYXRlIGRl
YWRsb2NrIGFzIEFuZHkgbWVudGlvbnMpDQotIGVkaXQgdGhlIGNhbmRpZGF0ZSBjb25maWcNCi0g
dmFsaWRhdGUgY2FuZGlkYXRlIGNvbmZpZw0KLSBjb21taXQgY2FuZGlkYXRlIHRvIHJ1bm5pbmcN
Ci0gcmVsZWFzZSBsb2NrIG9uIGNhbmRpZGF0ZSBhbmQgcnVubmluZw0KDQoNCk9uIEp1bCAxNCwg
MjAxNiwgYXQgMTI6MDMgUE0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIDxqYXNvbi5zdGVy
bmVAbm9raWEuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tPj4gd3JvdGU6DQoNCkhp
IGFsbCwNCg0KSeKAmW0gbG9va2luZyBmb3Igb3BpbmlvbnMgb24gaG93IGEgY2xpZW50ICYgc2Vy
dmVyIG1pZ2h0IGludGVyYWN0IGZvciB0aGUgPGxvY2s+IFJQQyB3aGVuIGEgc2VydmVyIHN1cHBv
cnRzIGJvdGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlIERTLg0KDQpJIHN1c3BlY3Qg
dGhpcyBpcyBhbiB1bnVzdWFsIHNpdHVhdGlvbiAtPiBkb2VzIGFueW9uZSBvdXQgdGhlcmUgd29y
ayB3aXRoIG9yIGhhdmUgYSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyBib3Ro
ID8NCg0KVGhlIHNwaXJpdCBvZiBhIDxsb2NrPiBpcyB0byByZXNlcnZlIGV4Y2x1c2l2ZSBhY2Nl
c3MgdG8gYWx0ZXIgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIGRldmljZSwgYW5kIHRvIHByZXZl
bnQgb3RoZXIgY2xpZW50cyAob3IgbWFuYWdlbWVudCBpbnRlcmZhY2VzKSBmcm9tIGFsdGVyaW5n
IHRoZSBjb25maWcgaW4gdGhlIG1lYW50aW1lLiAgSSByZWFsaXplIHRoYXQgaW4gdGhlb3J5IHRo
ZSBsb2NrcyBhcmUg4oCccGVyLURT4oCdIChpLmUuIGluZGVwZW5kYW50KSBidXQgSSB0aGluayB0
aGF0IG1pZ2h0IGJlIHRvbyBzaW1wbGlzdGljIGZvciBhIHN5c3RlbSB3aXRoIGJvdGggd3JpdGFi
bGUtcnVubmluZyBhbmQgY2FuZGlkYXRlLg0KDQpJbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIGJv
dGggd3JpdGFibGUtcnVubmluZyAmIGNhbmRpZGF0ZSwgaXQgc2VlbXMgdG8gbWFrZSBzZW5zZSB0
aGF0IGEgPGxvY2s+IG9mIHRoZSBydW5uaW5nIERTIHdvdWxkIGFsc28gY2F1c2UgdGhlIHNlcnZl
ciB0byBpbXBsaWNpdGx5IGxvY2sgdGhlIGNhbmRpZGF0ZSAob3IgYXQgbGVhc3QgcmVqZWN0IGEg
bG9jayByZXF1ZXN0IG9mIHRoZSBjYW5kaWRhdGUpLiAgT3RoZXJ3aXNlIChpLmUuIGFjY2VwdGlu
ZyBhIHN1YnNlcXVlbnQgbG9jayBvZiB0aGUgY2FuZGlkYXRlKSB0aGUgY2xpZW50IG1heSBhc3N1
bWUgc2luY2UgaXQgaGFzIHRoZSBjYW5kaWRhdGUgbG9jayB0aGVuIGl0IGhhcyB0aGUgZXhjbHVz
aXZlIHJpZ2h0cyB0byB0aGUgY29uZmlnIGFuZCBjYW4gaGFwcGlseSBlZGl0ICYgY29tbWl0IHRo
ZSBjb25maWcuICBJdCB3b3VsZCBiZSBjb25mdXNpbmcgdG8gZXJyb3Igb24gdGhlIGNvbW1pdCAo
ZHVlIHRvIGxvY2tpbmcpIGFmdGVyIGhhdmluZyBhY2NlcHRlZCBhIGxvY2suDQoNClNpbWlsYXJs
eSBmb3IgdGhlIHJldmVyc2Ugc2l0dWF0aW9uIC0+IGlmIGEgY2xpZW50IHRha2VzIGEgY2FuZGlk
YXRlIDxsb2NrPiB0aGVuIGNvdWxkbuKAmXQgaXQgYXNzdW1lIHRoYXQgbm9ib2R5IGNhbiBzdWJz
ZXF1ZW50bHkgYmxvY2sgdGhlaXIgY29tbWl0IGJ5IHRha2luZyBhIGxvY2sgb2YgdGhlIHJ1bm5p
bmcgRFMgPw0KDQpJdCBzZWVtcyBsaWtlIHRoZSBzZXJ2ZXIgc2hvdWxkIG1hbmFnZSB0aGlzIGlu
dGVyYWN0aW9uIGFuZCBhdm9pZCBnaXZpbmcgYW4g4oCcT0vigJ0gdG8gY2xpZW50cyB0YWtpbmcg
dGhlIHR3byBsb2NrcyBvbiB0aGUgdHdvIGRhdGFzdG9yZXMuDQoNCk9uIHRoZSBvdGhlciBoYW5k
IHRoaXMgY291bGQgYWxsIGJlIGxlZnQgdXAgdG8gdGhlIGNsaWVudHMgdG8gZGVhbCB3aXRoLiAg
Q2xpZW50cyB3b3VsZCBoYXZlIHRvIHNlZSB0aGF0IGEgc2VydmVyIGhhcyBib3RoIGEgd3JpdGVh
YmxlLXJ1bm5pbmcgYW5kIGEgY2FuZGlkYXRlIERTIGFuZCB0YWtlIGEgbG9jayBvZiBib3RoLiAg
IEJ1dCB0aGF0IHdvdWxkIHJlcXVpcmUgYWxsIGNsaWVudHMgdG8gaGF2ZSB0aGF0IGJlaGF2aW9y
IChpbnN0ZWFkIG9mIHRoZSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyB0aGUgMiBEU2VzIGRlYWxpbmcg
d2l0aCB0aGlzKS4gIEl0IGFsc28gaGFzIHJhY2UgY29uZGl0aW9ucyB3aGVyZSB0aGUgY2xpZW50
IHRha2VzIDEgbG9jayBidXQgc29tZW9uZSBlbHNlIGdldHMgdGhlIHNlY29uZCBsb2NrLg0KDQpP
cGluaW9ucyBhcHByZWNpYXRlZC4NClJlZ2FyZHMsDQpKYXNvbg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5l
dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpl
dGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQpN
YWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhh
bmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCCB3B2US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj
YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x
OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v
cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz
IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm
b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt
c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1h
aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U
ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxUeXBpY2Fs
IHRyYW5zYWN0aW9u4oCdIHdpdGggd2hhdCBOQyBjbGllbnQgYW5kIHdoYXQgTkMgc2VydmVyID88
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkRpZCB0aGUgTkMgc2VydmVyIGFkdmVydGlzZSBib3RoIHdyaXRhYmxlLXJ1bm5p
bmcgYW5kIGNhbmRpZGF0ZSBjYXBhYmlsaXRpZXMgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgYSBzZXJ2ZXIgb25s
eSBhZHZlcnRpc2VzIGNhbmRpZGF0ZSAoYW5kIG5vdCB3cml0YWJsZS1ydW5uaW5nKSB0aGVuIEni
gJlkIG9ubHkgZXhwZWN0IHRoZSBjbGllbnQgdG8gZXZlciBsb2NrIHRoZSBjYW5kaWRhdGUuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5KYXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1haGVzaCBKZXRoYW5hbmRhbmkgW21h
aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh
eSwgSnVseSAxNCwgMjAxNiAxNzo1Mzxicj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAoTm9r
aWEgLSBDQSk8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6
IFtOZXRjb25mXSAmbHQ7bG9jayZndDsgaW4gYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBib3RoIHdy
aXRhYmxlLXJ1bm5pbmcgYW5kIGNhbmRpZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkphc29uLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAxNCwgMjAxNiwgYXQgMTozNCBQTSwgU3Rlcm5lLCBKYXNv
biAoTm9raWEgLSBDQSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29t
Ij5qYXNvbi5zdGVybmVAbm9raWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SGkgTWFoZXNoLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SeKAmW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHlvdXIgZmlyc3Qgc3RhdGVtZW50
LiZuYnNwOyBDYW4geW91IGV4cGxhaW4gZnVydGhlciA/Jm5ic3A7IEFyZSB5b3Ugc2F5aW5nIHRo
YXQgb24gYSBzeXN0ZW0gdGhhdCBzdXBwb3J0cyBib3RoIHdyaXRhYmxlLXJ1bm5pbmcgYW5kIGNh
bmRpZGF0ZQ0KIHlvdSB0aGluayBjbGllbnRzIG1heSBqdXN0IHRha2UgdGhlIGxvY2sgb24gdGhl
IGNhbmRpZGF0ZSwgZG8gdGhlaXIgdXBkYXRlZCwgY29tbWl0IGFuZCB0aGVuIHJlbGVhc2UgdGhl
IGxvY2sgPyZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoYXQgaXMgcmVhc29uYWJsZS9wb3NzaWJsZS48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkgd2FzIHN0YXRpbmcgd2FzIGEgc3RhdGVtZW50IG9m
IGZhY3QuIEhlcmUgaXMgYSB0eXBpY2FsIHRyYW5zYWN0aW9uIHRoYXQgSSBzZWUuIE5vdGljZSwg
bm8gZWZmb3J0IHRvIGxvY2sgdGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtycGMg
eG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsgJm5ic3A7ICZuYnNwO21lc3NhZ2UtaWQ9JnF1b3Q7MiZxdW90OyZndDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbHQ7bG9jayZn
dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAmbmJzcDsgJmx0O3RhcmdldCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtjYW5kaWRhdGUv
Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7ICZuYnNwOyAmbHQ7L3RhcmdldCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbHQ7L2xvY2smZ3Q7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L3JwYyZndDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3Jw
Yy1yZXBseSBtZXNzYWdlLWlkPeKAnDImcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7eG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6
MS4wJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7ICZsdDtvay8mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L3JwYy1yZXBseSZndDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3JwYyB4bWxucz0mcXVv
dDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7bWVzc2FnZS1pZD0mcXVvdDszJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZsdDtlZGl0LWNvbmZpZyB4bWxu
czpuYz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsm
Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsgJm5ic3A7ICZsdDt0YXJnZXQmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7Y2FuZGlkYXRl
LyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyAmbmJzcDsgJmx0Oy90YXJnZXQmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbHQ7dGVzdC1v
cHRpb24mZ3Q7dGVzdC10aGVuLXNldCZsdDsvdGVzdC1vcHRpb24mZ3Q7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZsdDtl
cnJvci1vcHRpb24mZ3Q7cm9sbGJhY2stb24tZXJyb3ImbHQ7L2Vycm9yLW9wdGlvbiZndDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm
bmJzcDsgJmx0O2NvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IOKApiBjb25maWcgc3R1ZmY8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm
bmJzcDsgJmx0Oy9jb25maWcmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJmx0Oy9lZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsvcnBjJmd0OzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7cnBj
LXJlcGx5IG1lc3NhZ2UtaWQ9JnF1b3Q7MyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDt4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFz
ZToxLjAmcXVvdDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsgJmx0O29rLyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsvcnBjLXJlcGx5Jmd0OzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7cnBjIHhtbG5zPSZx
dW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDttZXNzYWdlLWlkPSZxdW90OzQmcXVvdDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJmx0O2NvbW1pdCZndDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm
bmJzcDsgJmx0O2NvbmZpcm1lZC8mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJmx0Oy9jb21taXQmZ3Q7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7
L3JwYyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmx0O3JwYy1yZXBseSBtZXNzYWdlLWlkPSZxdW90OzQmcXVvdDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7eG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpu
czpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZsdDtvay8mZ3Q7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L3JwYy1yZXBseSZndDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0
O3JwYyB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAm
cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyAmbmJzcDsgJm5ic3A7bWVzc2FnZS1pZD0mcXVvdDs1JnF1b3Q7Jmd0OzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZsdDtj
b21taXQvJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmx0Oy9ycGMmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9JnF1b3Q7NSZx
dW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxucz0mcXVvdDt1cm46
aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJmx0O29rLyZn
dDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZs
dDsvcnBjLXJlcGx5Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtycGMgeG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1z
OnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwO21lc3NhZ2UtaWQ9
JnF1b3Q7NiZxdW90OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOyAmbHQ7dW5sb2NrJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbHQ7dGFyZ2V0Jmd0
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJmx0O2NhbmRpZGF0ZS8mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZsdDsvdGFyZ2V0
Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7ICZsdDsvdW5sb2NrJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9ycGMmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtycGMtcmVwbHkgbWVzc2FnZS1pZD0mcXVv
dDs2JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zPSZxdW90
O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyZndDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbHQ7
b2svJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZsdDsvcnBjLXJlcGx5Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7cnBjIHhtbG5zPSZxdW90O3VybjppZXRmOnBh
cmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDttZXNzYWdl
LWlkPSZxdW90OzcmcXVvdDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJmx0O2Nsb3NlLXNlc3Npb24vJmd0OzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9ycGMmZ3Q7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+QXMgZm9yIHByZXZlbnRpbmcgb3RoZXIgbWdtbnQuIGludGVyZmFjZXMgZnJvbSBpbnRlcmZl
cmluZyAtJmd0OyBJIHRoaW5rIFJGQzYyNDEgaXMgcmVhc29uYWJseSBjbGVhciB0aGF0IHNob3Vs
ZCBiZSBwcmV2ZW50ZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRkaXRpb25hbGx5LCB0aGUgc3lzdGVtPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2lsbCBlbnN1cmUgdGhhdCB0aGVz
ZSBsb2NrZWQgY29uZmlndXJhdGlvbiByZXNvdXJjZXMgd2lsbCBub3QgYmU8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb2RpZmllZCBieSBvdGhlciBub24tTkVU
Q09ORiBtYW5hZ2VtZW50IG9wZXJhdGlvbnMgc3VjaCBhcyBTTk1QPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIENMSS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB0aGUgZ2VuZXJhbCB3b3JrZmxvdyBidXQg
dGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGNsaWVudCBzaG91bGQgZXhwbGljaXRseSBnZXQg
Ym90aCBsb2Nrcywgb3Igd2hldGhlciB0aGUgc2VydmVyIHNpZGUgc2hvdWxkIGltcGxpY2l0bHkg
dGFrZQ0KIGJvdGggbG9ja3MgKGkuZS4gcHJldmVudCBzZXBhcmF0ZSBtb2RpZmljYXRpb25zL2xv
Y2sgb2YgdGhlIG90aGVyIERTKS4mbmJzcDsgSXQgaXNu4oCZdCBvYnZpb3VzIGJ1dCBJIGxlYW4g
dG93YXJkcyB0aGUgc2VydmVyIHNpZGUgaGFuZGxpbmcgdGhpcyBzaXR1YXRpb24gKGVzcGVjaWFs
bHkgc2luY2UgdGhlIGNvbWJpbmF0aW9uIG9mIHdyaXRlYWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRh
dGUgc3VwcG9ydCBpcyBzb21ld2hhdCByYXJlKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkphc29uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYWhlc2gNCiBKZXRoYW5hbmRh
bmkgWzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWFpbHRvOm1qZXRo
YW5hbmRhbmlAZ21haWwuY29tPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBKdWx5IDE0LCAyMDE2IDE2OjAxPGJy
Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj5TdGVybmUsIEphc29uIChOb2tpYSAtIENBKTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TmV0Y29uZjxicj4NCjxiPlN1
YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj5SZTogW05ldGNvbmZdICZsdDtsb2NrJmd0OyBpbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIGJv
dGggd3JpdGFibGUtcnVubmluZyBhbmQgY2FuZGlkYXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgc2VlIGNsaWVudHMgYWNxdWlyaW5nIGxvY2sgb24gdGhlIGNhbmRpZGF0ZSBjb25maWcg
YnV0IG5vdCBvbiBydW5uaW5nLiBZb3UgYXJlIHJpZ2h0IHRoYXQgaXQgZG9lcyBub3QgcHJldmVu
dCwgc2F5IFJFU1RDT05GIG9yIGV2ZW4gQ0xJIGZyb20gdXBkYXRpbmcgdGhlIHJ1bm5pbmctY29u
ZmlnIGRpcmVjdGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHdvcmtmbG93IGZvciB3
aGF0IHNob3VsZCBiZSBoYXBwZW5pbmcgaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g
YWNxdWlyZSBsb2NrIG9uIGNhbmRpZGF0ZSBhbmQgcnVubmluZyAoY2FuIGNyZWF0ZSBkZWFkbG9j
ayBhcyBBbmR5IG1lbnRpb25zKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBlZGl0IHRoZSBjYW5kaWRhdGUgY29uZmln
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4tIHZhbGlkYXRlIGNhbmRpZGF0ZSBjb25maWc8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gY29tbWl0
IGNhbmRpZGF0ZSB0byBydW5uaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHJlbGVhc2UgbG9jayBvbiBjYW5kaWRh
dGUgYW5kIHJ1bm5pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1
bCAxNCwgMjAxNiwgYXQgMTI6MDMgUE0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpICZsdDs8
YSBocmVmPSJtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+amFzb24uc3Rlcm5lQG5va2lhLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgYWxsLDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J4oCZbSBsb29raW5nIGZvciBv
cGluaW9ucyBvbiBob3cgYSBjbGllbnQgJmFtcDsgc2VydmVyIG1pZ2h0IGludGVyYWN0IGZvciB0
aGUgJmx0O2xvY2smZ3Q7IFJQQyB3aGVuIGEgc2VydmVyIHN1cHBvcnRzIGJvdGggd3JpdGFibGUt
cnVubmluZyBhbmQgY2FuZGlkYXRlIERTLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+SSBzdXNwZWN0IHRoaXMgaXMgYW4gdW51c3VhbCBzaXR1YXRpb24gLSZndDsgZG9l
cyBhbnlvbmUgb3V0IHRoZXJlIHdvcmsgd2l0aCBvciBoYXZlIGEgc2VydmVyIGltcGxlbWVudGF0
aW9uIHRoYXQgc3VwcG9ydHMgYm90aCA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPlRoZSBzcGlyaXQgb2YgYSAmbHQ7bG9jayZndDsgaXMgdG8gcmVzZXJ2ZSBleGNs
dXNpdmUgYWNjZXNzIHRvIGFsdGVyIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBkZXZpY2UsIGFu
ZCB0byBwcmV2ZW50IG90aGVyIGNsaWVudHMgKG9yIG1hbmFnZW1lbnQgaW50ZXJmYWNlcykgZnJv
bSBhbHRlcmluZyB0aGUNCiBjb25maWcgaW4gdGhlIG1lYW50aW1lLiZuYnNwOyBJIHJlYWxpemUg
dGhhdCBpbiB0aGVvcnkgdGhlIGxvY2tzIGFyZSDigJxwZXItRFPigJ0gKGkuZS4gaW5kZXBlbmRh
bnQpIGJ1dCBJIHRoaW5rIHRoYXQgbWlnaHQgYmUgdG9vIHNpbXBsaXN0aWMgZm9yIGEgc3lzdGVt
IHdpdGggYm90aCB3cml0YWJsZS1ydW5uaW5nIGFuZCBjYW5kaWRhdGUuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIGEgc2VydmVyIHRoYXQgc3VwcG9ydHMgYm90
aCB3cml0YWJsZS1ydW5uaW5nICZhbXA7IGNhbmRpZGF0ZSwgaXQgc2VlbXMgdG8gbWFrZSBzZW5z
ZSB0aGF0IGEgJmx0O2xvY2smZ3Q7IG9mIHRoZSBydW5uaW5nIERTIHdvdWxkIGFsc28gY2F1c2Ug
dGhlIHNlcnZlciB0byBpbXBsaWNpdGx5IGxvY2sgdGhlIGNhbmRpZGF0ZQ0KIChvciBhdCBsZWFz
dCByZWplY3QgYSBsb2NrIHJlcXVlc3Qgb2YgdGhlIGNhbmRpZGF0ZSkuJm5ic3A7IE90aGVyd2lz
ZSAoaS5lLiBhY2NlcHRpbmcgYSBzdWJzZXF1ZW50IGxvY2sgb2YgdGhlIGNhbmRpZGF0ZSkgdGhl
IGNsaWVudCBtYXkgYXNzdW1lIHNpbmNlIGl0IGhhcyB0aGUgY2FuZGlkYXRlIGxvY2sgdGhlbiBp
dCBoYXMgdGhlIGV4Y2x1c2l2ZSByaWdodHMgdG8gdGhlIGNvbmZpZyBhbmQgY2FuIGhhcHBpbHkg
ZWRpdCAmYW1wOyBjb21taXQgdGhlIGNvbmZpZy4mbmJzcDsNCiBJdCB3b3VsZCBiZSBjb25mdXNp
bmcgdG8gZXJyb3Igb24gdGhlIGNvbW1pdCAoZHVlIHRvIGxvY2tpbmcpIGFmdGVyIGhhdmluZyBh
Y2NlcHRlZCBhIGxvY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PlNpbWlsYXJseSBmb3IgdGhlIHJldmVyc2Ugc2l0dWF0aW9uIC0mZ3Q7IGlmIGEgY2xpZW50IHRh
a2VzIGEgY2FuZGlkYXRlICZsdDtsb2NrJmd0OyB0aGVuIGNvdWxkbuKAmXQgaXQgYXNzdW1lIHRo
YXQgbm9ib2R5IGNhbiBzdWJzZXF1ZW50bHkgYmxvY2sgdGhlaXIgY29tbWl0IGJ5IHRha2luZyBh
IGxvY2sgb2YgdGhlDQogcnVubmluZyBEUyA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkl0IHNlZW1zIGxpa2UgdGhlIHNlcnZlciBzaG91bGQgbWFuYWdlIHRoaXMg
aW50ZXJhY3Rpb24gYW5kIGF2b2lkIGdpdmluZyBhbiDigJxPS+KAnSB0byBjbGllbnRzIHRha2lu
ZyB0aGUgdHdvIGxvY2tzIG9uIHRoZSB0d28gZGF0YXN0b3Jlcy48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gdGhlIG90aGVyIGhhbmQgdGhpcyBjb3VsZCBhbGwg
YmUgbGVmdCB1cCB0byB0aGUgY2xpZW50cyB0byBkZWFsIHdpdGguJm5ic3A7IENsaWVudHMgd291
bGQgaGF2ZSB0byBzZWUgdGhhdCBhIHNlcnZlciBoYXMgYm90aCBhIHdyaXRlYWJsZS1ydW5uaW5n
IGFuZCBhIGNhbmRpZGF0ZSBEUyBhbmQgdGFrZQ0KIGEgbG9jayBvZiBib3RoLiZuYnNwOyZuYnNw
OyBCdXQgdGhhdCB3b3VsZCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIGhhdmUgdGhhdCBiZWhhdmlv
ciAoaW5zdGVhZCBvZiB0aGUgc2VydmVyIHRoYXQgc3VwcG9ydHMgdGhlIDIgRFNlcyBkZWFsaW5n
IHdpdGggdGhpcykuJm5ic3A7IEl0IGFsc28gaGFzIHJhY2UgY29uZGl0aW9ucyB3aGVyZSB0aGUg
Y2xpZW50IHRha2VzIDEgbG9jayBidXQgc29tZW9uZSBlbHNlIGdldHMgdGhlIHNlY29uZCBsb2Nr
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PcGluaW9ucyBhcHBy
ZWNpYXRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJl
Z2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5KYXNv
bjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh
bj48YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjpwdXJwbGUiPk5ldGNvbmZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldGNvbmY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9
Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp
bC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCCB3B2US70TWXCHMBA11z_--


From nobody Fri Jul 15 12:06:31 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B196B12D7A7 for ; Fri, 15 Jul 2016 12:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbW5nP6S7GG5 for ; Fri, 15 Jul 2016 12:06:28 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7975312D8E5 for ; Fri, 15 Jul 2016 12:06:27 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id x130so167900641vkc.0 for ; Fri, 15 Jul 2016 12:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZuwZ2HtuNAVxk6ARE+W7DEsp1wfgZdO1l2N1x1HrunY=; b=CRbWKsysHWeOBuOBCUAo2H2X7mgVPeP5MG1juvaKqgfSWk95OPT+v0nqGNLNYaGWCO 18iy1LAFLJAALUVSMhfVWw5JD8CSfiyEamSVNBj6aZhcaZfz7PH1nMulEYbQFeZ8B5E9 +ZlIFMVW6i258CdifVEt7vDtFAxTu6vaywzDJAQcDNNPgImclP0XQcE4toHjVvBZiHnM 4f9k7vTq5r+b+I1l+RlaPQytkVoAqhpt0L06ub1UgqFzCXiI3yn8hiVsPJvyo90jYHSD TwvIRwAkdo5XlJqknJHbcbFLH7jthWvBUpXgUOGBC3LBkqZPIZlupWhZgUPFXzhPiXFt vUiA==
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; bh=ZuwZ2HtuNAVxk6ARE+W7DEsp1wfgZdO1l2N1x1HrunY=; b=iMyh9P1pjN4wimAih23zX9c9tIH0ce2c0DEmLyMCKmhQYztkgc0m0EdhHmTNdBkl3c 6n/WfFDdEeM60Og92jFZT49dNRorP0FD0TyQe9RiXGr9eNxJS/uT++fghbBcmF+g78Ok trpOPn/hUP51tWc5ACUhM64NkU2j0TOKVEw4EepwApZJZGJDpbN0kohhSNr0GHJgx5gy Tmak+MOfF5ACpR1ayfJpK36R4Tt3Asv4wJxJTyvAchRJKDyVK0/XUY480JbkAsaO0LED w8oJcV6XQgZj+66LWeJTQvV5dRxp+f8TRcGJvV+5QW1UqsFC43L3oE1duqEmnKAJW+07 Fjmw==
X-Gm-Message-State: ALyK8tJHWuPDyKkEBHAQ4Ll+e0+EtO3z7qHtJq2LEKfmM0xtjKIieXl4i8sF1WF2k3MvL5ezAnt3OzywqkTIvA==
X-Received: by 10.176.67.4 with SMTP id k4mr11234911uak.47.1468609586565; Fri, 15 Jul 2016 12:06:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Fri, 15 Jul 2016 12:06:25 -0700 (PDT)
In-Reply-To: 
References:  <24228C18-B5F2-4B63-A5D6-FAB5522C6541@gmail.com>  <40DE01C9-4528-493A-A0C6-08AA4648D900@gmail.com> 
From: Andy Bierman 
Date: Fri, 15 Jul 2016 12:06:25 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Content-Type: multipart/alternative; boundary=94eb2c09507ab8ccb70537b150bc
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf]  in a server that supports both writable-running and candidate
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 19:06:29 -0000

--94eb2c09507ab8ccb70537b150bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 15, 2016 at 11:48 AM, Sterne, Jason (Nokia - CA) <
jason.sterne@nokia.com> wrote:

> Hi Mahesh,
>
>
>
> =E2=80=9CTypical transaction=E2=80=9D with what NC client and what NC ser=
ver ?
>
>
>
> Did the NC server advertise both writable-running and candidate
> capabilities ?
>
>
>
> If a server only advertises candidate (and not writable-running) then I=
=E2=80=99d
> only expect the client to ever lock the candidate.
>
>
>

No features are required to lock running.
The running datastore must exist.
It can be locked for reading by another client.
(e.g., the client wants a stable snapshot of the config)

The section on  clearly states that the commit will
fail if another session has locked the candidate or running datastores.



> Jason
>
>
>


Andy


> *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
> *Sent:* Thursday, July 14, 2016 17:53
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Netconf
> *Subject:* Re: [Netconf]  in a server that supports both
> writable-running and candidate
>
>
>
> Jason,
>
>
>
> On Jul 14, 2016, at 1:34 PM, Sterne, Jason (Nokia - CA) <
> jason.sterne@nokia.com> wrote:
>
>
>
> Hi Mahesh,
>
>
>
> I=E2=80=99m not sure I understand your first statement.  Can you explain =
further
> ?  Are you saying that on a system that supports both writable-running an=
d
> candidate you think clients may just take the lock on the candidate, do
> their updated, commit and then release the lock ?   I think that is
> reasonable/possible.
>
>
>
> What I was stating was a statement of fact. Here is a typical transaction
> that I see. Notice, no effort to lock the running configuration.
>
>
>
> 
>      message-id=3D"2">
>
>   
>
>     
>
>       
>
>     
>
>   
>
> 
>
>
>
> 
>            xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>
>   
>
> 
>
>
>
> 
>      message-id=3D"3">
>
>   
>
>     
>
>       
>
>     
>
>     test-then-set
>
>     rollback-on-error
>
>     
>
>       =E2=80=A6 config stuff
>
>     
>
>   
>
> 
>
>
>
> 
>            xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>
>   
>
> 
>
>
>
> 
>      message-id=3D"4">
>
>   
>
>     
>
>   
>
> 
>
>
>
> 
>            xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>
>   
>
> 
>
>
>
> 
>      message-id=3D"5">
>
>   
>
> 
>
>
>
> 
>            xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>
>   
>
> 
>
>
>
> 
>      message-id=3D"6">
>
>   
>
>     
>
>       
>
>     
>
>   
>
> 
>
>
>
> 
>            xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>
>   
>
> 
>
>
>
> 
>      message-id=3D"7">
>
>   
>
> 
>
>
>
>
>
>
>
> As for preventing other mgmnt. interfaces from interfering -> I think
> RFC6241 is reasonably clear that should be prevented:
>
>
>
> Additionally, the system
>
>       will ensure that these locked configuration resources will not be
>
>       modified by other non-NETCONF management operations such as SNMP
>
>       and CLI.
>
>
>
> I agree with the general workflow but the question is whether the client
> should explicitly get both locks, or whether the server side should
> implicitly take both locks (i.e. prevent separate modifications/lock of t=
he
> other DS).  It isn=E2=80=99t obvious but I lean towards the server side h=
andling
> this situation (especially since the combination of writeable-running and
> candidate support is somewhat rare).
>
>
>
> Jason
>
>
>
> *From:* Mahesh Jethanandani [mailto:mjethanandani@gmail.com
> ]
> *Sent:* Thursday, July 14, 2016 16:01
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Netconf
> *Subject:* Re: [Netconf]  in a server that supports both
> writable-running and candidate
>
>
>
> I see clients acquiring lock on the candidate config but not on running.
> You are right that it does not prevent, say RESTCONF or even CLI from
> updating the running-config directly.
>
>
>
> A workflow for what should be happening is:
>
>
>
> - acquire lock on candidate and running (can create deadlock as Andy
> mentions)
>
> - edit the candidate config
>
> - validate candidate config
>
> - commit candidate to running
>
> - release lock on candidate and running
>
>
>
>
>
> On Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia - CA) <
> jason.sterne@nokia.com> wrote:
>
>
>
> Hi all,
>
>
>
> I=E2=80=99m looking for opinions on how a client & server might interact =
for the
>  RPC when a server supports both writable-running and candidate DS.
>
>
>
>
> I suspect this is an unusual situation -> does anyone out there work with
> or have a server implementation that supports both ?
>
>
>
> The spirit of a  is to reserve exclusive access to alter the
> configuration of the device, and to prevent other clients (or management
> interfaces) from altering the config in the meantime.  I realize that in
> theory the locks are =E2=80=9Cper-DS=E2=80=9D (i.e. independant) but I th=
ink that might be
> too simplistic for a system with both writable-running and candidate.
>
>
>
> In a server that supports both writable-running & candidate, it seems to
> make sense that a  of the running DS would also cause the server to
> implicitly lock the candidate (or at least reject a lock request of the
> candidate).  Otherwise (i.e. accepting a subsequent lock of the candidate=
)
> the client may assume since it has the candidate lock then it has the
> exclusive rights to the config and can happily edit & commit the config.
> It would be confusing to error on the commit (due to locking) after havin=
g
> accepted a lock.
>
>
>
> Similarly for the reverse situation -> if a client takes a candidate
>  then couldn=E2=80=99t it assume that nobody can subsequently block=
 their
> commit by taking a lock of the running DS ?
>
>
>
> It seems like the server should manage this interaction and avoid giving
> an =E2=80=9COK=E2=80=9D to clients taking the two locks on the two datast=
ores.
>
>
>
> On the other hand this could all be left up to the clients to deal with.
> Clients would have to see that a server has both a writeable-running and =
a
> candidate DS and take a lock of both.   But that would require all client=
s
> to have that behavior (instead of the server that supports the 2 DSes
> dealing with this).  It also has race conditions where the client takes 1
> lock but someone else gets the second lock.
>
>
>
> Opinions appreciated.
>
> Regards,
>
> Jason
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> Mahesh Jethanandani
>
> mjethanandani@gmail.com
>
>
>
> Mahesh Jethanandani
>
> mjethanandani@gmail.com
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--94eb2c09507ab8ccb70537b150bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jul 15, 2016 at 11:48 AM, Sterne, Jason (Nokia - CA) <ja=
son.sterne@nokia.com> wrote:




Hi Mahesh,<=
/span>


=C2=A0


=E2=80=9CTypical transact=
ion=E2=80=9D with what NC client and what NC server ?<=
/p>

=C2=A0


Did the NC server adverti=
se both writable-running and candidate capabilities ?<=
/p>

=C2=A0


If a server only advertis=
es candidate (and not writable-running) then I=E2=80=99d only expect the cl=
ient to ever lock the candidate.


=C2=A0
<=
/div>

No features are required to loc=
k running.
The running datastore must exist.
It can be =
locked for reading by another client.
(e.g., the client wants a s=
table snapshot of the config)

The section on <c=
ommit> clearly states that the commit will
fail if another ses=
sion has locked the candidate or running datastores.

=C2=A0


Jason


=C2=A0
<=
/div>


Andy
=
=C2=A0
<=
u>






From: Mahesh J=
ethanandani [mailto:mjethanandani@gmail.com]


Sent: Thursday, July 14, 2016 17:53

To: Sterne, Jason (Nokia - CA)

Cc: Netconf

Subject: Re: [Netconf] <lock> in a server that supports both w=
ritable-running and candidate






=C2=A0


Jason,




=C2=A0








On Jul 14, 2016, at 1:34 PM, Sterne, Jason (Nokia - =
CA) <jason.s=
terne@nokia.com> wrote:




=C2=A0






Hi Mahesh,<=
u>






=C2=A0






I=E2=80=99m not sure I un=
derstand your first statement.=C2=A0 Can you explain further ?=C2=A0 Are yo=
u saying that on a system that supports both writable-running and candidate
 you think clients may just take the lock on the candidate, do their update=
d, commit and then release the lock ?=C2=A0=C2=A0 I think that is reasonabl=
e/possible.










=C2=A0




What I was stating was a statement of fact. Here is =
a typical transaction that I see. Notice, no effort to lock the running con=
figuration.








=C2=A0






<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf=
:base:1.0"






=C2=A0 =C2=A0 =C2=A0message-id=3D"2">






=C2=A0 <lock>






=C2=A0 =C2=A0 <target>






=C2=A0 =C2=A0 =C2=A0 <candidate/>






=C2=A0 =C2=A0 </target>






=C2=A0 </lock>






</rpc>






=C2=A0






<rpc-reply message-id=3D=E2=80=9C2"






=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0">






=C2=A0 <ok/>






</rpc-reply>






=C2=A0






<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf=
:base:1.0"






=C2=A0 =C2=A0 =C2=A0message-id=3D"3">






=C2=A0 <edit-config xmlns:nc=3D"urn:ietf:par=
ams:xml:ns:netconf:base:1.0">






=C2=A0 =C2=A0 <target>






=C2=A0 =C2=A0 =C2=A0 <candidate/>






=C2=A0 =C2=A0 </target>








=C2=A0 =C2=A0 <test-option>test-then-set</t=
est-option>






=C2=A0 =C2=A0 <error-option>rollback-on-error&=
lt;/error-option>






=C2=A0 =C2=A0 <config>






=C2=A0 =C2=A0 =C2=A0 =E2=80=A6 config stuff






=C2=A0 =C2=A0 </config>






=C2=A0 </edit-config>






</rpc>






=C2=A0






<rpc-reply message-id=3D"3"






=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0">






=C2=A0 <ok/>






</rpc-reply>






=C2=A0






<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf=
:base:1.0"






=C2=A0 =C2=A0 =C2=A0message-id=3D"4">






=C2=A0 <commit>






=C2=A0 =C2=A0 <confirmed/>






=C2=A0 </commit>










</rpc>






=C2=A0






<rpc-reply message-id=3D"4"






=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0">






=C2=A0 <ok/>






</rpc-reply>






=C2=A0






<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf=
:base:1.0"






=C2=A0 =C2=A0 =C2=A0message-id=3D"5">






=C2=A0 <commit/>






</rpc>






=C2=A0








<rpc-reply message-id=3D"5"






=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0">






=C2=A0 <ok/>






</rpc-reply>








=C2=A0






<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf=
:base:1.0"






=C2=A0 =C2=A0 =C2=A0message-id=3D"6">






=C2=A0 <unlock>






=C2=A0 =C2=A0 <target>






=C2=A0 =C2=A0 =C2=A0 <candidate/>






=C2=A0 =C2=A0 </target>






=C2=A0 </unlock>






</rpc>






=C2=A0






<rpc-reply message-id=3D"6"






=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:netconf:base:1.0">






=C2=A0 <ok/>








</rpc-reply>






=C2=A0






<rpc xmlns=3D"urn:ietf:params:xml:ns:netconf=
:base:1.0"






=C2=A0 =C2=A0 =C2=A0message-id=3D"7">






=C2=A0 <close-session/>






</rpc>








=C2=A0






=C2=A0












=C2=A0






As for preventing other m=
gmnt. interfaces from interfering -> I think RFC6241 is reasonably clear=
 that should be prevented:






=C2=A0






Additionally, the system<=
/span>






=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 will ensure that these locked configuration resources will not be






=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 modified by other non-NETCONF management operations such as SNMP






=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 and CLI.






=C2=A0






I agree with the general =
workflow but the question is whether the client should explicitly get both =
locks, or whether the server side should implicitly take
 both locks (i.e. prevent separate modifications/lock of the other DS).=C2=
=A0 It isn=E2=80=99t obvious but I lean towards the server side handling th=
is situation (especially since the combination of writeable-running and can=
didate support is somewhat rare).






=C2=A0






Jason






=C2=A0










From:=C2=
=A0Mahesh
 Jethanandani [mailto:mjethanandani@gmail.com]=C2=A0

Sent:=C2=A0Thursday, July 14, 2016 16:01

To:=C2=A0Sterne, Jason (Nokia - CA)

Cc:=C2=A0Netconf

Subject:=C2=A0Re: [Netconf] <lock> in a server th=
at supports both writable-running and candidate










=C2=A0








I see clients acquiring lock on the candidate config=
 but not on running. You are right that it does not prevent, say RESTCONF o=
r even CLI from updating the running-config directly.










=C2=A0










A workflow for what should be happening is:










=C2=A0










- acquire lock on candidate and running (can create =
deadlock as Andy mentions)










- edit the candidate config










- validate candidate config










- commit candidate to running










- release lock on candidate and running








=C2=A0










=C2=A0












On Jul 14, 2016, at 12:03 PM, Sterne, Jason (Nokia -=
 CA) <jason.sterne@nokia.com> wrote:<=
u>








=C2=A0










Hi all,










=C2=A0










I=E2=80=99m looking for opinions on how=
 a client & server might interact for the <lock> RPC when a serve=
r supports both writable-running and candidate DS.=C2=A0=C2=A0=











=C2=A0










I suspect this is an unusual situation =
-> does anyone out there work with or have a server implementation that =
supports both ?










=C2=A0










The spirit of a <lock> is to rese=
rve exclusive access to alter the configuration of the device, and to preve=
nt other clients (or management interfaces) from altering the
 config in the meantime.=C2=A0 I realize that in theory the locks are =E2=
=80=9Cper-DS=E2=80=9D (i.e. independant) but I think that might be too simp=
listic for a system with both writable-running and candidate.=











=C2=A0










In a server that supports both writable=
-running & candidate, it seems to make sense that a <lock> of the=
 running DS would also cause the server to implicitly lock the candidate
 (or at least reject a lock request of the candidate).=C2=A0 Otherwise (i.e=
. accepting a subsequent lock of the candidate) the client may assume since=
 it has the candidate lock then it has the exclusive rights to the config a=
nd can happily edit & commit the config.=C2=A0
 It would be confusing to error on the commit (due to locking) after having=
 accepted a lock.










=C2=A0










Similarly for the reverse situation -&g=
t; if a client takes a candidate <lock> then couldn=E2=80=99t it assu=
me that nobody can subsequently block their commit by taking a lock of the
 running DS ?










=C2=A0










It seems like the server should manage =
this interaction and avoid giving an =E2=80=9COK=E2=80=9D to clients taking=
 the two locks on the two datastores.










=C2=A0










On the other hand this could all be lef=
t up to the clients to deal with.=C2=A0 Clients would have to see that a se=
rver has both a writeable-running and a candidate DS and take
 a lock of both.=C2=A0=C2=A0 But that would require all clients to have tha=
t behavior (instead of the server that supports the 2 DSes dealing with thi=
s).=C2=A0 It also has race conditions where the client takes 1 lock but som=
eone else gets the second lock.










=C2=A0










Opinions appreciated.<=
/u>










Regards,










Jason=C2=A0<=
u>










=C2=A0








______________________________________=
_________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/ne=
tconf












=C2=A0














Mahesh Jethanandani























=C2=A0










Mahesh Jethanandani







=C2=A0






=C2=A0




=C2=A0<=
/p>



=C2=A0









_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c09507ab8ccb70537b150bc--


From nobody Fri Jul 15 12:19:54 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0C712DA66 for ; Fri, 15 Jul 2016 12:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 w6v7fd1djLuy for ; Fri, 15 Jul 2016 12:19:49 -0700 (PDT)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0940512DA1F for ; Fri, 15 Jul 2016 12:19:48 -0700 (PDT)
Received: from [192.168.10.101] ([24.13.90.46]) by p3plsmtpa06-04.prod.phx3.secureserver.net with  id K7Kn1t005100Es8017KnKm; Fri, 15 Jul 2016 12:19:48 -0700
To: "Sterne, Jason (Nokia - CA)" , Jan Lindblad , Andy Bierman 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> 
From: Xiang Li 
Message-ID: <57893742.6040903@seguesoft.com>
Date: Fri, 15 Jul 2016 14:19:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000609010901010500020705"
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jul 2016 19:19:53 -0000

This is a multi-part message in MIME format.
--------------000609010901010500020705
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/15/2016 1:37 PM, Sterne, Jason (Nokia - CA) wrote:
>
> (f) should be accepted without an error IMO.
>

Ok. If f) is accepted then it indicates the server chooses to delete an 
empty container
or it basically ignore the operation to create only a NP container node.

RFC6020 only says "MAY delete",

    If a container does not have a "presence" statement and the last
    child node is deleted, the NETCONF server MAY delete the container.


What if a server faithfully creates the NP structure node in e), then f) 
will be
rejected since the container node has already "existed" and can't
be "created" again.


> The presence/existence (or not) of an NP-container should not affect 
> the behavior.
>

Semantically I believe that is true.

> Maybe that isn’t spelled out in the RFCs but I have my doubts many 
> implementations would reject (f).
>

I think RFC6020bis should clarify the expected behavior when a client 
attempts to
create empty NP container without child nodes for whatever reason 
(unless this
is not allowed).

same thing when a client attempts to delete twice a container node.

I think the lengthy discussion warrants this to be spelled out, one way 
or another.

-Xiang


> *From:*Xiang Li [mailto:xiangli@seguesoft.com]
> *Sent:* Friday, July 15, 2016 14:11
> *To:* Jan Lindblad; Andy Bierman; Sterne, Jason (Nokia - CA)
> *Cc:* Netconf
> *Subject:* Re: [Netconf] What should a server response be?
>
> On 7/15/2016 1:46 AM, Jan Lindblad wrote:
>
>     In order to reach rough consensus on the interpretation of the
>     default-operation=none sequence, I think we need to start with
>     coming to a common understanding of what NP containers are. Can NP
>     containers be "created" and "deleted" just like P containers?
>
>     Here's a test to see if there is any difference between the
>     behavior of p and np containers:
>
>     list t {
>
>         key a;
>
>         leaf a { type uint32; }
>
>         container np {
>
>             must "../a > 10";
>
>         }
>
>         container p {
>
>             presence "...";
>
>             must "../a > 20";
>
>         }
>
>     }
>
>     The config is initially empty. Now, would it be possible to
>
>     a) create an instance with a = 5 if there is no mention of np and
>     p in the edit-config?
>
>     b) create an instance with a = 5 if np (but not p) is "created" in
>     the edit-config?
>
>     c) create an instance with a = 15 if there is no mention of np and
>     p in the edit-config?
>
>     d) create an instance with a = 15 if p is created in the edit-config?
>
>     My own answer is that only operation c is allowed. "creation" of
>     an NP container is irrelevant, while creation of a P container
>     makes a difference.
>
>
> Yes I agree
>
>
>
> An NP container is simply a structural element, and does not need to 
> be "created" to exist,
>
>
> I understand the "does not need to be 'created' to exist" part. The 
> confusion arises about what is a compliant
> implementation when a client does want to create it explicitly for 
> whatever reason. Using your example
> (a very good example, by the way)
>
> e) create with a = 15,  and also create np  explicitly
>
> and then follows up with an additional edit-config
> f)  merge with a = 15, and create np explicitly again
>
>
> should a compliant server reject f) or not?
>
>
> but empty NP containers MAY not be reported since they are meaningless 
> anyway.
>
> I agree
>
>
> If must statements in np containers are in effect even if the client 
> isn't explicitly "creating" or mentioning the container, then I find 
> it hard to understand the viewpoint that "creation" of NP containers 
> makes any difference.
>
>
> It doesn't. What I am trying to figure out is  how a compliant server 
> implementation
>  should handle  the "operation"  on a NP container node in a 
> .
>
> -Xiang
>
>
>
>
> /jan
>
>                 I guess I don’t really see NP-containers as “configâ€.
>                 They are just structure and filtered out when empty. 
>                 I don’t really see this as the server “deleting†those
>                 containers.  It just suppresses them in 
>                 output.
>
>             Please show me the RFC text that says the server can
>             filter out NP containers.
>
>             All config=true data nodes are config.
>
>         In a very technical sense, I suppose the above statement is
>         correct. An NP container is of course config true if it sits
>         in the config true part of the tree. At the same time I agree
>         with Janson's view that NP containers are just structure, so
>         the question of their "existence" is moot.
>
>         Here's what RFC 6020, sec 7.5 says on the topic:
>
>             YANG supports two styles of containers, those that exist only for
>
>             organizing the hierarchy of data nodes, and those whose presence in
>
>             the configuration has an explicit meaning.
>
>         So NP containers "exist only for organizing the hierarchy"
>         while a P container "has an explicit meaning". I guess this
>         implies NP containers having no meaning. Further down in
>         7.5.1, re P containers, it is noted that:
>
>             In the second style, the presence of the container itself is
>
>             configuration data, representing a single bit of configuration data.
>
>             The container acts as both a configuration knob and a means of
>
>             organizing related configuration.  These containers are explicitly
>
>             created and deleted.
>
>         Based on these fragments, I conclude that NP containers have
>         zero bits of information. This means the existence/absence of
>         an NP container cannot be known/stored/remembered even
>         internally by a conforming system. The existence/absence of an
>         NP container is a moot question. It's a bit like asking for
>         the value of a void function. It's there, it has a name, but
>         no value.
>
>         Implementations that receive a  or  request
>         that contains an NP container will have to decide whether to
>         include the NP container in the response or not. Since the
>         existence of the NP container cannot be read from a
>         database/etc (it has zero bits of information), the
>         implementation will have to use some other way to determine
>         whether to include it or not.
>
>         In order to make the life easier for implementors, the
>         following MAY was introduced in sec 7.5.7:
>
>             A NETCONF server that replies to a  or  request MAY
>
>             choose not to send a container element if the container node does not
>
>             have the "presence" statement and no child nodes exist.
>
>         So the NP container has to be included if it has children, or
>         else the structural function of the container would be lost.
>         If the NP container is empty, it may or may not be sent. Since
>         an NP container has zero bits of information, this decision
>         would not be based on whether it has been previously "created"
>         or "deleted", but on implementation considerations. One
>         possible approach is to always include it, another to actually
>         check if there are any children, and only return it then.
>
>         Either way, NP containers alone have no meaning/information,
>         they are only there for structure.
>
>
>
>         A false must-stmt in an NP-container is still an error.
>
>         Certainly. Must statements on an NP container are always
>         evaluated, even if the container hasn't been "created" or
>         mentioned by a client, and even if it has no child elements.
>
>
>
>         As Lada has pointed out many times, the text about
>
>         NP containers not being part of the data model is just wrong.
>
>         I think the length of this discussion implies we should
>         include this topic in the upcoming YANG FAQ.
>
>                 The server should not error in the cases Mahesh &
>                 Einar show -> the presence/existence of NP-containers
>                 shouldn’t really affect behavior (since they aren’t
>                 really config).
>
>         I agree with the above.
>
>             But I’m not positive what you mean by “manager needs to
>             guardâ€.  Do you agree that the server should not error in
>             those cases below ?
>
>         The YANG text says a server MAY delete an empty NP container.
>
>         Using default-operation=none implies that the client is sure
>         the nodes for operation=none
>
>         actually exist.  Because of this YANG detail, the client
>         cannot be sure so using
>
>         default-operation=none may not work.
>
>         I disagree with this conclusion. Even using
>         default-operation=none the transactions must be guaranteed to
>         work by a conforming implementation. NP containers cannot be
>         created/deleted in a deeper sense of the word since they have
>         zero information content. They can only be referred to. Any
>         must statements within the container must be evaluated
>         regardless of the client ever mentioning the container.
>
>     I do not agree that default-operation=none does not apply to NP
>     containers.
>
>     This is why it was such a bad decision to spread little pieces of
>     NETCONF
>
>     all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
>
>     and it does not say anything about special treatment for NP
>     containers.
>
>         none:  The target datastore is unaffected by the configuration
>
>                  in the  parameter, unless and until the incoming
>
>                  configuration data uses the "operation" attribute to request
>
>                  a different operation.  If the configuration in the 
>
>                  parameter contains data for which there is not a
>
>                  corresponding level in the target datastore, an 
>
>                  is returned with an  value of data-missing.
>
>                  Using "none" allows operations like "delete" to avoid
>
>                  unintentionally creating the parent hierarchy of the element
>
>                  to be deleted.
>
>         /jan
>
>     Andy
>

--------------000609010901010500020705
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/15/2016 1:37 PM, Sterne, Jason
      (Nokia - CA) wrote:

    

    

      
      
      
      

        
(f) should be accepted without an error
            IMO.  

          

      

    

    

    Ok. If f) is accepted then it indicates the server chooses to delete
    an empty container

    or it basically ignore the operation to create only a NP container
    node.

    

    RFC6020 only says "MAY delete",

    
   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

    

    What if a server faithfully creates the NP structure node in e),
    then f) will be 

    rejected since the container node has already "existed" and can't

    be "created" again.

    

    

    

      

        
 The presence/existence (or not) of an
            NP-container should not affect the behavior.  

          

      

    

    

    Semantically I believe that is true. 

    

    

      

        
 Maybe that isn’t spelled out in the RFCs
            but I have my doubts many implementations would reject (f).

        
 

      

    

    

    I think RFC6020bis should clarify the expected behavior when a
    client attempts to 

    create empty NP container without child nodes for whatever reason
    (unless this

    is not allowed).

    

    same thing when a client attempts to delete twice a container node.

    

    I think the lengthy discussion warrants this to be spelled out, one
    way or another.

    

    -Xiang

    

    

    

      

        

          

            
From: Xiang Li
                [mailto:xiangli@seguesoft.com]
                

                Sent: Friday, July 15, 2016 14:11

                To: Jan Lindblad; Andy Bierman; Sterne, Jason
                (Nokia - CA)

                Cc: Netconf

                Subject: Re: [Netconf] What should a server
                response be?

          

        

        
 

        

          
On 7/15/2016 1:46 AM, Jan Lindblad wrote:

        

        

          
In order to reach rough consensus on the
            interpretation of the default-operation=none sequence, I
            think we need to start with coming to a common understanding
            of what NP containers are. Can NP containers be "created"
            and "deleted" just like P containers? 

          

            
 

          

          

            
Here's a test to see if there is any
              difference between the behavior of p and np containers:

          

          

            
 

          

          

            
list t {

          

          

            
    key a;

          

          

            
    leaf a { type uint32; }

          

          

            
    container np {

          

          

            
        must "../a > 10";

          

          

            
    }

          

          

            
    container p {

          

          

            
        presence "...";

          

          

            
        must "../a > 20";

          

          

            
    }

          

          

            
}

          

          

            
 

          

          

            
The config is initially empty. Now,
              would it be possible to

          

          

            
 

          

          

            
a) create an instance with a = 5 if
              there is no mention of np and p in the edit-config?

          

          

            
b) create an instance with a = 5 if np
              (but not p) is "created" in the edit-config?

          

          

            
c) create an instance with a = 15 if
              there is no mention of np and p in the edit-config?

          

          

            
d) create an instance with a = 15 if p
              is created in the edit-config?

          

        

        

          

            
My own answer is that only operation c
              is allowed. "creation" of an NP container is irrelevant,
              while creation of a P container makes a difference.

          

        

        


          Yes I agree 

          

          

          

          

        

          
An NP container is simply a structural
            element, and does not need to be "created" to exist,

        

        


          I understand the "does not need to be 'created' to exist"
          part. The confusion arises about what is a compliant
          

          implementation when a client does want to create it explicitly
          for whatever reason. Using your example
          

          (a very good example, by the way)

          

          e) create with a = 15,  and also create np  explicitly

          

          and then follows up with an additional edit-config

          f)  merge with a = 15, and create np explicitly again 

          

          

          should a compliant server reject f) or not?

          

          

          

        

          
but empty NP containers MAY not be
            reported since they are meaningless anyway.

        

        

          
 

        

        
I agree 

          

          

          

        

          
If must statements in np containers are
            in effect even if the client isn't explicitly "creating" or
            mentioning the container, then I find it hard to understand
            the viewpoint that "creation" of NP containers makes any
            difference.

        

        

          
 

        

        


          It doesn't. What I am trying to figure out is  how a compliant
          server implementation

           should handle  the "operation"  on a NP container node in a
          <edit-config>.  

          

          -Xiang

          

          

          

          

          

        

          
/jan

        

        

          
 

        

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
I guess I don’t really see
                                            NP-containers as “configâ€. 
                                            They are just structure and
                                            filtered out when empty.  I
                                            don’t really see this as the
                                            server “deleting†those
                                            containers.  It just
                                            suppresses them in
                                            <get-config> output.   

                                      

                                    

                                  

                                  

                                    
Please
                                        show me the RFC text that says
                                        the server can filter out NP
                                        containers.

                                  

                                  

                                    
All
                                        config=true data nodes are
                                        config.

                                  

                                

                              

                            

                          

                          

                            
 

                          

                          

                            
In a very
                                technical sense, I suppose the above
                                statement is correct. An NP container is
                                of course config true if it sits in the
                                config true part of the tree. At the
                                same time I agree with Janson's view
                                that NP containers are just structure,
                                so the question of their "existence" is
                                moot. 

                          

                          

                            
 

                          

                          

                            
Here's what RFC
                                6020, sec 7.5 says on the topic:

                          

                          

                            
 

                          

                          

                            
   YANG supports two styles of containers, those that exist only for

                            
   organizing the hierarchy of data nodes, and those whose presence in

                            
   the configuration has an explicit meaning.

                            

                              
 

                            

                          

                          

                            
So NP
                                containers "exist only for organizing
                                the hierarchy" while a P container "has
                                an explicit meaning". I guess this
                                implies NP containers having no meaning.
                                Further down in 7.5.1, re P containers,
                                it is noted that:

                          

                          

                            
 

                          

                          

                            
   In the second style, the presence of the container itself is

                            
   configuration data, representing a single bit of configuration data.

                            

                              
   The container acts as both a configuration knob and a means of

                              
   organizing related configuration.  These containers are explicitly

                              
   created and deleted.

                            

                            

                              
 

                            

                          

                          

                            
Based on these
                                fragments, I conclude that NP containers
                                have zero bits of information. This
                                means the existence/absence of an NP
                                container cannot be
                                known/stored/remembered even internally
                                by a conforming system. The
                                existence/absence of an NP container is
                                a moot question. It's a bit like asking
                                for the value of a void function. It's
                                there, it has a name, but no value.

                          

                          

                            
 

                          

                          

                            
Implementations
                                that receive a <get> or
                                <get-config> request that contains
                                an NP container will have to decide
                                whether to include the NP container in
                                the response or not. Since the existence
                                of the NP container cannot be read from
                                a database/etc (it has zero bits of
                                information), the implementation will
                                have to use some other way to determine
                                whether to include it or not.

                          

                          

                            
 

                          

                          

                            
In order to
                                make the life easier for implementors,
                                the following MAY was introduced in sec
                                7.5.7:

                          

                          

                            
 

                          

                          

                            
   A NETCONF server that replies to a <get> or <get-config> request MAY

                            
   choose not to send a container element if the container node does not

                            
   have the "presence" statement and no child nodes exist.

                            

                              
 

                            

                          

                          

                            
So the NP
                                container has to be included if it has
                                children, or else the structural
                                function of the container would be lost.
                                If the NP container is empty, it may or
                                may not be sent. Since an NP container
                                has zero bits of information, this
                                decision would not be based on whether
                                it has been previously "created" or
                                "deleted", but on implementation
                                considerations. One possible approach is
                                to always include it, another to
                                actually check if there are any
                                children, and only return it then.

                          

                          

                            
 

                          

                          

                            
Either way, NP
                                containers alone have no
                                meaning/information, they are only there
                                for structure.

                          

                          


                              

                              

                          

                            

                              

                                

                                  
A false
                                      must-stmt in an NP-container is
                                      still an error.

                                

                              

                            

                          

                          

                            
 

                          

                          

                            
Certainly. Must
                                statements on an NP container are always
                                evaluated, even if the container hasn't
                                been "created" or mentioned by a client,
                                and even if it has no child elements.

                          

                          


                              

                              

                          

                            

                              

                                

                                  
As Lada
                                      has pointed out many times, the
                                      text about

                                

                                

                                  
NP
                                      containers not being part of the
                                      data model is just wrong.

                                

                              

                            

                          

                          

                            
 

                          

                          

                            
I think the
                                length of this discussion implies we
                                should include this topic in the
                                upcoming YANG FAQ.

                          

                          

                            

                              

                                

                                  

                                    

                                      

                                        
The server should not error in
                                            the cases Mahesh & Einar
                                            show -> the
                                            presence/existence of
                                            NP-containers shouldn’t
                                            really affect behavior
                                            (since they aren’t really
                                            config). 

                                      

                                    

                                  

                                

                              

                            

                          

                          
I agree with the
                              above.

                              

                              

                          

                            

                              

                                

                                  

                                    

                                      
But I’m not positive what you
                                          mean by “manager needs to
                                          guardâ€.  Do you agree that the
                                          server should not error in
                                          those cases below ?

                                    

                                  

                                

                                

                                  
The YANG
                                      text says a server MAY delete an
                                      empty NP container.

                                

                                

                                  
Using
                                      default-operation=none implies
                                      that the client is sure the nodes
                                      for operation=none

                                

                                

                                  
actually
                                      exist.  Because of this YANG
                                      detail, the client cannot be sure
                                      so using

                                

                                

                                  
default-operation=none
                                      may not work.

                                

                              

                            

                          

                          

                            
 

                          

                          

                            
I disagree with
                                this conclusion. Even using
                                default-operation=none the transactions
                                must be guaranteed to work by a
                                conforming implementation. NP containers
                                cannot be created/deleted in a deeper
                                sense of the word since they have zero
                                information content. They can only be
                                referred to. Any must statements within
                                the container must be evaluated
                                regardless of the client ever mentioning
                                the container.

                          

                          

                            
 

                          

                        

                      

                    

                    

                      
 

                    

                    

                      
 

                    

                    

                      
I do not agree that
                          default-operation=none does not apply to NP
                          containers.

                    

                    

                      
 

                    

                    

                      
This is why it was
                          such a bad decision to spread little pieces of
                          NETCONF

                    

                    

                      
all over the YANG
                          RFC. RFC 6241 defines the 'default-operation'
                          leaf

                    

                    

                      
and it does not say
                          anything about special treatment for NP
                          containers.

                    

                    

                      
 

                    

                    

                      
   none:  The target datastore is unaffected by the configuration

                      
            in the <config> parameter, unless and until the incoming

                      
            configuration data uses the "operation" attribute to request

                      
            a different operation.  If the configuration in the <config>

                      
            parameter contains data for which there is not a

                      
            corresponding level in the target datastore, an <rpc-error>

                      
            is returned with an <error-tag> value of data-missing.

                      
            Using "none" allows operations like "delete" to avoid

                      
            unintentionally creating the parent hierarchy of the element

                      
            to be deleted.

                    

                    

                      
 

                    

                    

                      
 

                    

                    

                      

                        

                          

                            
/jan

                          

                          

                            
 

                          

                        

                      

                    

                  

                  
 

                

                

                  
Andy

                

              

            

          

          
 

        

      

    

  


--------------000609010901010500020705--


From nobody Sat Jul 16 02:58:35 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB66F12D85E for ; Sat, 16 Jul 2016 02:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qNoEMhHHxaGp for ; Sat, 16 Jul 2016 02:58:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BDE9012D848 for ; Sat, 16 Jul 2016 02:58:32 -0700 (PDT)
Received: from [10.61.200.217] (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id CDB1E1AE0099; Sat, 16 Jul 2016 11:58:29 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_554A7FA7-5C93-4BFE-8885-31D3E9B5FCDD"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: <57893742.6040903@seguesoft.com>
Date: Sat, 16 Jul 2016 09:31:38 +0200
Message-Id: <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com>
To: Xiang Li 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 09:58:35 -0000

--Apple-Mail=_554A7FA7-5C93-4BFE-8885-31D3E9B5FCDD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0E7A0603-87D3-4DE5-A47E-BDBD614E00D3"


--Apple-Mail=_0E7A0603-87D3-4DE5-A47E-BDBD614E00D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>> (f) should be accepted without an error IMO.
>=20
> Ok. If f) is accepted then it indicates the server chooses to delete =
an empty container
> or it basically ignore the operation to create only a NP container =
node.

I agree with this.

I also agree that RFC 6020 could spell this out in a more direct way. =
Currently the description of NP and P containers does not contain a =
table with the properties of each, but instead enumerates how P =
containers differ from NP containers in plain english. In order to build =
a such a table, I've collected quotes on each type here:

P-container qoutes:
- "presence in the configuration has an explicit meaning"
- "presence of the container itself is configuration data"
- "representing a single bit of configuration data"
- "These containers are explicitly created and deleted"
- "The "presence" statement assigns a meaning to the presence of a =
container in the data tree"

NP-container qoutes:
- "exist only for organizing the hierarchy of data nodes"
- "container has no meaning of its own, existing only to contain child =
nodes"
- "the container is used to give some structure to the data, and it =
carries no meaning by itself"
- "MAY choose not to send a container element if the container node does =
not have the "presence" statement and no child nodes exist"
- "a client ... must be prepared to handle the case that a container =
node without a "presence" statement is not present"

Based on the above quotes, I believe this to be a fair description of =
the P and NP container differences in a tabular form:

                                  | P-container | NP-container |
----------------------------------+-------------+--------------+
Organizing the hierarchy          |      Y      |       Y      |
May have child nodes              |      Y      |       Y      |
Existence has meaning             |      Y      |       N      |
Is configuration data             |      Y      |       N      |
Information content               |    1 bit    |    0 bits    |
Explicitly created and deleted    |      Y      |       N      |
Suppress when empty               |      N      |      MAY     |
----------------------------------+-------------+--------------+

With this background, I consider it clear that "creation" and "deletion" =
of P-containers has no effect on the configuration. In fact, a =
conforming implementation cannot even remember/know if a P-container has =
been created or not since it has zero bits of information. P-containers =
aren't really configuration data, even if they may be located in the =
config true part of the world.

If anyone sees anything wrong, unfounded or unclear with the table =
above, I think it would be of high general interest that this is pointed =
out asap.

/jan


--Apple-Mail=_0E7A0603-87D3-4DE5-A47E-BDBD614E00D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


(f) should be accepted without an error =
IMO.  

Ok. If f) is accepted then it indicates the =
server chooses to delete an empty container
or it basically ignore the operation to create =
only a NP container node.

I agree =
with this.

I also agree that RFC =
6020 could spell this out in a more direct way. Currently the =
description of NP and P containers does not contain a table with the =
properties of each, but instead enumerates how P containers differ from =
NP containers in plain english. In order to build a such a table, I've =
collected quotes on each type here:

P-container qoutes:
- "presence in the =
configuration has an explicit meaning"
- "presence of the =
container itself is configuration data"
- "representing a =
single bit of configuration data"
- "These containers are =
explicitly created and deleted"
- "The "presence" statement =
assigns a meaning to the presence of a container in the data =
tree"

NP-container =
qoutes:
- "exist only for organizing the hierarchy of data =
nodes"
- "container has no meaning of its own, =
existing only to contain child nodes"
- "the container =
is used to give some structure to the data, and it carries no meaning by =
itself"
- "MAY choose not to send a container element if the =
container node does not have the "presence" statement and no child nodes =
exist"
- "a client ... must be prepared to handle the case =
that a container node without a "presence" statement is not =
present"

Based on the above quotes, =
I believe this to be a fair description of the P and NP container =
differences in a tabular form:

            =
                    =
  | P-container | NP-container |
----------------------------------+-------------+--------------=
+
Organizing the =
hierarchy          |      Y =
     |       Y     =
 |
May have =
child nodes              |   =
   Y      |       Y   =
   |
Existence has meaning           =
  |      Y      |     =
  N      |
Is configuration data   =
          |      Y     =
 |       N     =
 |
Information =
content               |   =
 1 bit    |    0 bits   =
 |
Explicitly =
created and deleted    |      Y     =
 |       N     =
 |
Suppress when =
empty               |     =
 N      |      MAY     =
|
----------------------------------+-------------+--------------=
+

With this background, I consider it =
clear that "creation" and "deletion" of P-containers has no effect on =
the configuration. In fact, a conforming implementation cannot even =
remember/know if a P-container has been created or not since it has zero =
bits of information. P-containers aren't really configuration data, even =
if they may be located in the config true part of the =
world.

If anyone sees anything =
wrong, unfounded or unclear with the table above, I think it would be of =
high general interest that this is pointed out asap.

/jan

=

--Apple-Mail=_0E7A0603-87D3-4DE5-A47E-BDBD614E00D3--

--Apple-Mail=_554A7FA7-5C93-4BFE-8885-31D3E9B5FCDD
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

iQEcBAEBCgAGBQJXieLaAAoJEBSCnbqufIisYMkH/29FPi0SMOavyIhG8BmPH48j
yIyqXHbM1BVcHvxqPW9V/9OdGGOTSH9LWJl/VRtNDA0E2gwMSwRljNAYb5bhsc7j
0sIuSb0D+pqV6duQp92lobpFioOWN1Uu6CuoUuqJQgaIye9jaZSoRBFLpUuhlxwF
3HLj2aIw70s1UdkgwyjMOVLNd39pOPmER5PNao9hRcDGgCFrycwY04pViJ2UjVYV
7hFl+Nm8yoRRA9j/4bhfXl3cu38wXHmYP5r3vWA7NDsJ/0drp5ubUSI4zC+38VJx
QLGJHNiN0sLQGPJcUzVXULadpwli2u8PaTbdx6cj9s7Dn0yslCPI1bzgu1qJpEw=
=hfm+
-----END PGP SIGNATURE-----

--Apple-Mail=_554A7FA7-5C93-4BFE-8885-31D3E9B5FCDD--


From nobody Sat Jul 16 03:03:26 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC9B12D85E for ; Sat, 16 Jul 2016 03:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PG-T3ujslyJe for ; Sat, 16 Jul 2016 03:03:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 593F512B075 for ; Sat, 16 Jul 2016 03:03:23 -0700 (PDT)
Received: from [10.61.200.217] (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 59F0D1AE0099; Sat, 16 Jul 2016 12:03:22 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E1CAF035-B183-407E-B40D-8E444EFB3EA8"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>
Date: Sat, 16 Jul 2016 12:03:24 +0200
Message-Id: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>
To: Xiang Li 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 10:03:25 -0000

--Apple-Mail=_E1CAF035-B183-407E-B40D-8E444EFB3EA8
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6357DC2B-CB6A-490A-B950-54E7EEC571F5"


--Apple-Mail=_6357DC2B-CB6A-490A-B950-54E7EEC571F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Typo, corrected below:

> In fact, a conforming implementation cannot even remember/know if a =
P-container has been created or not since it has zero bits of =
information.

In fact, a conforming implementation cannot even remember/know if an =
NP-container has been created or not since it has zero bits of =
information.

/jan


--Apple-Mail=_6357DC2B-CB6A-490A-B950-54E7EEC571F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Typo, corrected below:

In fact, a conforming implementation cannot even =
remember/know if a P-container has been created or not since it has zero =
bits of information.

In =
fact, a conforming implementation cannot even remember/know if an =
NP-container has been created or not since it has zero bits of =
information.

/jan

=

--Apple-Mail=_6357DC2B-CB6A-490A-B950-54E7EEC571F5--

--Apple-Mail=_E1CAF035-B183-407E-B40D-8E444EFB3EA8
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

iQEcBAEBCgAGBQJXigZsAAoJEBSCnbqufIisPzcH/0ZOY+nFRmZqK4PB/RxSiGLn
n3/Rgy3GObMKZ9QexWByl1l/wyHmSRocWbBE6YdQrOsg9DdTqpW8/8JrldUnESMX
fXsKYbAyzNlSTE3XFBsLFxgzVjbG5ROpRhjqzGl+uKmasiVcUybtNg+Sr++oqEwC
h+gc92bt0ryzywHpKtTlyCnkw43fAgr7EgKNHEFNYqirZRHl0F2tJNdb04qzwEv4
ZRtwyx/u3UzjG3DB3a/I9sgxXevwOPV6UxQZ4yeyuT8BiG1VsDt/YOfw+gAsS1WN
Tg48DD3ovrz/YdLSIpsPTn7u2hb0WUCx6rqooton8sVeaOKy4VZ+mAghqT4wCeU=
=SwFW
-----END PGP SIGNATURE-----

--Apple-Mail=_E1CAF035-B183-407E-B40D-8E444EFB3EA8--


From nobody Sat Jul 16 11:07:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0532912D6B1; Sat, 16 Jul 2016 11:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuSRvb9vnafu; Sat, 16 Jul 2016 11:07:15 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00F812D0BC; Sat, 16 Jul 2016 11:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2102; q=dns/txt; s=iport; t=1468692435; x=1469902035; h=to:cc:from:subject:message-id:date:mime-version; bh=b0YHr8a+pUvwGx3bqsNUztwQxSxDsb8hzBvIN9/FD0Q=; b=nHYLdwFOPox2WMCiu0dLa4+7UEr7DjcYSzxkELmepOScu3JtwkitECXe qqnLXw02VY2ii15k6iQUQcEfSVH/4ivrGp0UetrSrbytU6aZtNQElOpKM blovtKqoLD8C2j4kmXNNUvvZZihdTHJajNorR/Fv80QT4rQXiVuc1uPXF 8=;
X-IronPort-AV: E=Sophos;i="5.28,374,1464652800";  d="scan'208,217";a="678302482"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 18:07:13 +0000
Received: from [10.61.161.254] ([10.61.161.254]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6GI7CjW029705; Sat, 16 Jul 2016 18:07:13 GMT
To: draft-gonzalez-netconf-5277bis@ietf.org
From: Benoit Claise 
Message-ID: <93ce4b92-09b7-74ac-028d-6bfac245ebc0@cisco.com>
Date: Sat, 16 Jul 2016 20:07:13 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------517FB6D5FA56033BE5E1E9D0"
Archived-At: 
Cc: "Carl Moberg \(camoberg\)" , NETCONF 
Subject: [Netconf] draft-gonzalez-netconf-5277bis-02.txt: YANG compilation error
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 18:07:17 -0000

This is a multi-part message in MIME format.
--------------517FB6D5FA56033BE5E1E9D0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors,

Part of the IETF hackathon today, I integrated confdc , as a second YANG 
module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. 
Reason? For example, confdc validates xpath while pyang doesn't.
And confdc found an issue with your draft, which is now flagged as 
failing the YANG compilation.
Please correct this issue.
Note: you're not alone, look at the green dip today on green graph 
!

During the hackathon today, Carl Moberg also integrated the confdc 
output in his www.yangalidtor.com.
This might help you.

Regards, Benoit





--------------517FB6D5FA56033BE5E1E9D0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear authors, 

    

    Part of the IETF hackathon today, I integrated confdc , as a second
    YANG module compiler, in
    http://www.claise.be/IETFYANGPageCompilation.html. Reason? For
    example, confdc validates xpath while pyang doesn't.

    And confdc found an issue with your draft, which is now flagged as
    failing the YANG compilation.

    Please correct this issue. 

    Note: you're not alone, look at the green dip
      today on green graph!

    

    During the hackathon today, Carl Moberg also integrated the confdc
    output in his www.yangalidtor.com.

    This might help you.

    

    Regards, Benoit

    

    

    

    

  


--------------517FB6D5FA56033BE5E1E9D0--


From nobody Sat Jul 16 11:18:39 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C88912B055; Sat, 16 Jul 2016 11:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZPPYDji2orM; Sat, 16 Jul 2016 11:18:35 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA0C12B04D; Sat, 16 Jul 2016 11:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2234; q=dns/txt; s=iport; t=1468693115; x=1469902715; h=to:cc:from:subject:message-id:date:mime-version; bh=Ryvkp3Mo+YaEihKeN3VPzMMeErE4J1CTxxIFhnu+pPM=; b=D4Dx88vZt5wbQmGNwCherr8llgA1fehlB5v8bSiS6TidBeTx7vVcTC5Y 79kqZ6dWhEwXJRZOsKWy5sL7vMyMhuCa3gDNLAZn20BOD0zFSvZpuKbCe cpZF89wiMT7Y3G32r+9nJb8C7d00FAwMnfjTOyKmeQD+SnEGWILhvu6ic Q=;
X-IronPort-AV: E=Sophos;i="5.28,375,1464652800";  d="scan'208,217";a="635749758"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 18:18:33 +0000
Received: from [10.61.161.254] ([10.61.161.254]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6GIIXmU031824; Sat, 16 Jul 2016 18:18:33 GMT
To: draft-ietf-netconf-server-model@ietf.org, NETCONF 
From: Benoit Claise 
Message-ID: <62b234e9-4402-0eb5-fd19-6786447395c3@cisco.com>
Date: Sat, 16 Jul 2016 20:18:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------E6746EFE25F04302BDA493E5"
Archived-At: 
Cc: "Carl Moberg \(camoberg\)" 
Subject: [Netconf] draft-ietf-netconf-server-model-09.txt: confdc found some new errors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 18:18:37 -0000

This is a multi-part message in MIME format.
--------------E6746EFE25F04302BDA493E5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors,

Part of the IETF hackathon today, I integrated confdc , as a second YANG 
module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. 
Reason? For example, confdc validates xpath while pyang doesn't.
And confdc found an issue with your draft, which is now flagged as 
failing the YANG compilation.
Please correct this issue.
Note: you're not alone, look at the green dip today on green graph 
!

During the hackathon today, Carl Moberg also integrated the confdc 
output in his www.yangalidtor.com.
This might help you.

Regards, Benoit


--------------E6746EFE25F04302BDA493E5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear authors,

    
 

      Part of the IETF hackathon today, I integrated confdc , as a
      second YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html.
      Reason? For example, confdc validates xpath while pyang doesn't.

      And confdc found an issue with your draft, which is now flagged as
      failing the YANG compilation.

      Please correct this issue. 

      Note: you're not alone, look at the green
        dip today on green graph!

      

      During the hackathon today, Carl Moberg also integrated the confdc
      output in his www.yangalidtor.com.

      This might help you.

      

      Regards, Benoit 

    

  


--------------E6746EFE25F04302BDA493E5--


From nobody Sat Jul 16 11:25:37 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF2E12B05A; Sat, 16 Jul 2016 11:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K68QSOpgbreL; Sat, 16 Jul 2016 11:25:35 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2C612B04D; Sat, 16 Jul 2016 11:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2223; q=dns/txt; s=iport; t=1468693534; x=1469903134; h=to:from:subject:message-id:date:mime-version; bh=EF80Z0Kf/4jd+sZe9CVueSOXQ2WeV/qiKdJO6e8qaRA=; b=Ptwp/KniaG/+elJq6koOmXZ1SR5Gf6y7m5uQn2yADx6u8IxlUz9bWLzp b8IlIHLtArOBXR1WdwTrj7/87gZqgUSWDtuNWq8EuDFC4BYkjAi4KrUmw GQzwxeLiqguX3EtlgEyMC2e1i0XvP8ZcytOhfq+Bhh0qMJBc10ZHjHw/P A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcEgBee4pX/xbLJq1chBUqUrNzhn0ih?= =?us-ascii?q?20BAQEBAQFmJ4UGJk8BPQJfAQwIAQGILA6wBY18AQEBAQYBAQEBI4YqgXiKFoJ?= =?us-ascii?q?aBZkkhhOITIFrToQLgwyFZ5AeVIN1OjIBhlUrgRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.28,375,1464652800";  d="scan'208,217";a="638591390"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 18:25:32 +0000
Received: from [10.61.161.254] ([10.61.161.254]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6GIPWxG000521; Sat, 16 Jul 2016 18:25:32 GMT
To: draft-ietf-netconf-zerotouch@ietf.org, NETCONF 
From: Benoit Claise 
Message-ID: 
Date: Sat, 16 Jul 2016 20:25:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------455D12115C9D6EEBA9E2B139"
Archived-At: 
Subject: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 18:25:36 -0000

This is a multi-part message in MIME format.
--------------455D12115C9D6EEBA9E2B139
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors,

Part of the IETF hackathon today, I integrated confdc , as a second YANG 
module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. 
Reason? For example, confdc validates xpath while pyang doesn't.
And confdc found an issue with your draft, which is now flagged as 
failing the YANG compilation.
Please correct this issue.
Note: you're not alone, look at the green dip today on green graph 
!

During the hackathon today, Carl Moberg also integrated the confdc 
output in his www.yangalidtor.com.
This might help you.

Regards, Benoit

--------------455D12115C9D6EEBA9E2B139
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear authors, 

    
 

      Part of the IETF hackathon today, I integrated confdc , as a
      second YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html.
      Reason? For example, confdc validates xpath while pyang doesn't.

      And confdc found an issue with your draft, which is now flagged as
      failing the YANG compilation.

      Please correct this issue. 

      Note: you're not alone, look at the green
        dip today on green graph!

      

      During the hackathon today, Carl Moberg also integrated the confdc
      output in his www.yangalidtor.com.

      This might help you.

      

      Regards, Benoit 

  


--------------455D12115C9D6EEBA9E2B139--


From nobody Sat Jul 16 11:43:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0A612D0DF; Sat, 16 Jul 2016 11:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejiCRyg_CbLA; Sat, 16 Jul 2016 11:43:07 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0126.outbound.protection.outlook.com [104.47.41.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320A1126FDC; Sat, 16 Jul 2016 11:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xAXoDhbCoLbPhga4IwfIiYuH3AbgJr6sIpQN0jHlFjA=; b=eZTGui3diaUE3wJt6DC4/0Sg2aK9niQilUh2PlGBoK23jyul+F6PlWyLjrMZ3vqJ3I0UitqU6C7lRT5A+7SepzZdw5omJVqrq1UZImm0S1xR6ceCkyGvRLe5qq5ycEMzphUKgN2iOw5UKdQvxcwya/xdom9kt2wA1+VWvlR+AHE=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Sat, 16 Jul 2016 18:43:02 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0549.003; Sat, 16 Jul 2016 18:43:02 +0000
From: Kent Watsen 
To: Benoit Claise , "draft-ietf-netconf-server-model@ietf.org" , NETCONF 
Thread-Topic: draft-ietf-netconf-server-model-09.txt: confdc found some new errors
Thread-Index: AQHR3456bDeXllHnTkO04QrR7fpSZaAbIZeA
Date: Sat, 16 Jul 2016 18:43:01 +0000
Message-ID: 
References: <62b234e9-4402-0eb5-fd19-6786447395c3@cisco.com>
In-Reply-To: <62b234e9-4402-0eb5-fd19-6786447395c3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.133.141.22]
x-ms-office365-filtering-correlation-id: 10254fac-508e-4205-f42d-08d3ada9042b
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:uQjMlFy9+S8UtOxvrjQ2ZWMBLSeNFHvFinYfft1XSDpuTnlB3yQ3X0zn41iyLvq39MvKdVeA9/CkL8pJFSTxstXavp/CNjp9IJMAqCsjTdK3QeND3inPE153p0b6ttZB7nHpypX5ALoYeeifRrh/YIju5ABTu+lefteR3y1VbBNHMNmLNP1Kxa5UQDPF5Xr6+Wo0zjTnv7P5iUJ2Vuwr5SvUcJij76hu25YJwgMQ7GZ0p1uFC+uDTEunX8KzM8uMZjkqJg+qYot7HsHgYXaUxZKG8mVqzonytXAvaTLYGXemixII+16DEh9nt+E9Qmb3hUe3iP7+gj6Yft7B1/jt8w==; 5:gt9iRyz6Oad/ipf/wWOT9ukcXDIpNtE0mSdY89Nmu8zEZAdeCo1SGR1HlVGnljX3jxQFvGc85kpz97hP2bOeV23bjHsRx61DFAlQCTOg9esZT8jrGDDthWkBXqm9LVEkQynHjl6B9h4v7SC81FLAoQ==; 24:+FRyNzobs0I/GQqPMSUEsjHLouq2zUvFaFs96O3WuCCX2miD9Hdw1IL/mYLW2g6e0O0aA2ZwQM6j6lT7NQfn26nLnx+8Tpjdqwnt0kPKIzo=; 7:+EZ6SQiYB7xjgKC6EYzmb6QZaKwLYacjomPFIN2L29K6Bz2Tu1YMlEX1bc7xGEBNjBwh8iu7cFgfRWuvVx0M46DUYv0VdyDB8AMGjWenoePRlSsLPSctBjY30iOiJg0S89i4AtnqsLOovgxO1HgKYdb+je7RUzWdABJXEmltoNIzGLwhz/dfTAkoiE+XfkRN9j2tg9e//LkZ1GFNjS/XyOHewoHBgTPsE6xIyXOtT3S9vNLfyOx9P5oSjLTkACRy
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);  SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(189002)(199003)(377454003)(19617315012)(83506001)(2900100001)(15975445007)(7846002)(6116002)(82746002)(36756003)(19580395003)(66066001)(50986999)(76176999)(16236675004)(92566002)(19625215002)(54356999)(77096005)(189998001)(99286002)(105586002)(81166006)(8676002)(8936002)(3280700002)(81156014)(4326007)(2950100001)(97736004)(106356001)(2906002)(86362001)(14971765001)(19580405001)(106116001)(1680700002)(102836003)(3660700001)(7906003)(9326002)(68736007)(7736002)(122556002)(83716003)(5002640100001)(586003)(19300405004)(10400500002)(5001770100001)(33656002)(230783001)(3846002)(4001350100001)(87936001)(101416001)(16601075003)(11100500001)(15395725005)(2501003)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CE7BEDB684E7430DB03EE2960D885D21junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2016 18:43:01.8357 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Cc: "Carl Moberg \(camoberg\)" 
Subject: Re: [Netconf] draft-ietf-netconf-server-model-09.txt: confdc found some new errors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 18:43:10 -0000

--_000_CE7BEDB684E7430DB03EE2960D885D21junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpIaSBCZW5vaXQsDQoNClRoaXMgcGFydGljdWxhciBkcmFmdCBpcyBubyBsb25nZXIgYW4gYWN0
aXZlIFdHIGRvY3VtZW50LCBhcyBpdCBoYXMgYmVlbiBzcGxpdCBpbnRvIGEgbnVtYmVyIG9mIG90
aGVyIGRyYWZ0cyBub3cuICBXaGF0IG5lZWRzIHRvIGJlIGRvbmUgdG8gcmVtb3ZlIGl0IGZyb20g
YmVpbmcgc2Nhbm5lZD8NCg0KVGhhbmtzLA0KS2VudA0KDQpGcm9tOiBCZW5vaXQgQ2xhaXNlIDxi
Y2xhaXNlQGNpc2NvLmNvbT4NCkRhdGU6IFNhdHVyZGF5LCBKdWx5IDE2LCAyMDE2IGF0IDg6MTgg
UE0NClRvOiAiZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbEBpZXRmLm9yZyIgPGRyYWZ0
LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9kZWxAaWV0Zi5vcmc+LCAibmV0Y29uZkBpZXRmLm9yZyIg
PG5ldGNvbmZAaWV0Zi5vcmc+DQpDYzogIkNhcmwgTW9iZXJnIChjYW1vYmVyZykiIDxjYW1vYmVy
Z0BjaXNjby5jb20+DQpTdWJqZWN0OiBkcmFmdC1pZXRmLW5ldGNvbmYtc2VydmVyLW1vZGVsLTA5
LnR4dDogY29uZmRjIGZvdW5kIHNvbWUgbmV3IGVycm9ycw0KUmVzZW50LUZyb206IDxhbGlhcy1i
b3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVy
Lm5ldD4sIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQpSZXNlbnQtRGF0
ZTogU2F0dXJkYXksIEp1bHkgMTYsIDIwMTYgYXQgODoxOCBQTQ0KDQpEZWFyIGF1dGhvcnMsDQoN
ClBhcnQgb2YgdGhlIElFVEYgaGFja2F0aG9uIHRvZGF5LCBJIGludGVncmF0ZWQgY29uZmRjICwg
YXMgYSBzZWNvbmQgWUFORyBtb2R1bGUgY29tcGlsZXIsIGluIGh0dHA6Ly93d3cuY2xhaXNlLmJl
L0lFVEZZQU5HUGFnZUNvbXBpbGF0aW9uLmh0bWwuIFJlYXNvbj8gRm9yIGV4YW1wbGUsIGNvbmZk
YyB2YWxpZGF0ZXMgeHBhdGggd2hpbGUgcHlhbmcgZG9lc24ndC4NCkFuZCBjb25mZGMgZm91bmQg
YW4gaXNzdWUgd2l0aCB5b3VyIGRyYWZ0LCB3aGljaCBpcyBub3cgZmxhZ2dlZCBhcyBmYWlsaW5n
IHRoZSBZQU5HIGNvbXBpbGF0aW9uLg0KUGxlYXNlIGNvcnJlY3QgdGhpcyBpc3N1ZS4NCk5vdGU6
IHlvdSdyZSBub3QgYWxvbmUsIGxvb2sgYXQgdGhlIGdyZWVuIGRpcCB0b2RheSBvbiBncmVlbiBn
cmFwaDxodHRwOi8vY2xhaXNlLmJlL0lFVEZZQU5HUGFnZUNvbXBpbGF0aW9uLnBuZz4hDQoNCkR1
cmluZyB0aGUgaGFja2F0aG9uIHRvZGF5LCBDYXJsIE1vYmVyZyBhbHNvIGludGVncmF0ZWQgdGhl
IGNvbmZkYyBvdXRwdXQgaW4gaGlzIHd3dy55YW5nYWxpZHRvci5jb208aHR0cDovL3d3dy55YW5n
YWxpZHRvci5jb20+Lg0KVGhpcyBtaWdodCBoZWxwIHlvdS4NCg0KUmVnYXJkcywgQmVub2l0DQoN
Cg==

--_000_CE7BEDB684E7430DB03EE2960D885D21junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhp
IEJlbm9pdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGlzIHBhcnRpY3VsYXIgZHJhZnQg
aXMgbm8gbG9uZ2VyIGFuIGFjdGl2ZSBXRyBkb2N1bWVudCwgYXMgaXQgaGFzIGJlZW4gc3BsaXQg
aW50byBhIG51bWJlciBvZiBvdGhlciBkcmFmdHMgbm93LiZuYnNwOyBXaGF0IG5lZWRzIHRvIGJl
IGRvbmUgdG8gcmVtb3ZlIGl0IGZyb20gYmVpbmcgc2Nhbm5lZD88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+S2Vu
dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9t
OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6Ymxh
Y2siPkJlbm9pdCBDbGFpc2UgJmx0O2JjbGFpc2VAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6
IDwvYj5TYXR1cmRheSwgSnVseSAxNiwgMjAxNiBhdCA4OjE4IFBNPGJyPg0KPGI+VG86IDwvYj4m
cXVvdDtkcmFmdC1pZXRmLW5ldGNvbmYtc2VydmVyLW1vZGVsQGlldGYub3JnJnF1b3Q7ICZsdDtk
cmFmdC1pZXRmLW5ldGNvbmYtc2VydmVyLW1vZGVsQGlldGYub3JnJmd0OywgJnF1b3Q7bmV0Y29u
ZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9i
PiZxdW90O0NhcmwgTW9iZXJnIChjYW1vYmVyZykmcXVvdDsgJmx0O2NhbW9iZXJnQGNpc2NvLmNv
bSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2Rl
bC0wOS50eHQ6IGNvbmZkYyBmb3VuZCBzb21lIG5ldyBlcnJvcnM8YnI+DQo8Yj5SZXNlbnQtRnJv
bTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1Ubzog
PC9iPktlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OywgJmx0O2ouc2Nob2Vu
d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTogPC9i
PlNhdHVyZGF5LCBKdWx5IDE2LCAyMDE2IGF0IDg6MTggUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGF1dGhv
cnMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGFy
dCBvZiB0aGUgSUVURiBoYWNrYXRob24gdG9kYXksIEkgaW50ZWdyYXRlZCBjb25mZGMgLCBhcyBh
IHNlY29uZCBZQU5HIG1vZHVsZSBjb21waWxlciwgaW4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuY2xh
aXNlLmJlL0lFVEZZQU5HUGFnZUNvbXBpbGF0aW9uLmh0bWwiPmh0dHA6Ly93d3cuY2xhaXNlLmJl
L0lFVEZZQU5HUGFnZUNvbXBpbGF0aW9uLmh0bWw8L2E+LiBSZWFzb24/IEZvciBleGFtcGxlLCBj
b25mZGMgdmFsaWRhdGVzIHhwYXRoIHdoaWxlIHB5YW5nIGRvZXNuJ3QuPGJyPg0KQW5kIGNvbmZk
YyBmb3VuZCBhbiBpc3N1ZSB3aXRoIHlvdXIgZHJhZnQsIHdoaWNoIGlzIG5vdyBmbGFnZ2VkIGFz
IGZhaWxpbmcgdGhlIFlBTkcgY29tcGlsYXRpb24uPGJyPg0KUGxlYXNlIGNvcnJlY3QgdGhpcyBp
c3N1ZS4gPGJyPg0KTm90ZTogeW91J3JlIG5vdCBhbG9uZSwgbG9vayBhdCA8YSBocmVmPSJodHRw
Oi8vY2xhaXNlLmJlL0lFVEZZQU5HUGFnZUNvbXBpbGF0aW9uLnBuZyI+DQp0aGUgZ3JlZW4gZGlw
IHRvZGF5IG9uIGdyZWVuIGdyYXBoPC9hPiE8YnI+DQo8YnI+DQpEdXJpbmcgdGhlIGhhY2thdGhv
biB0b2RheSwgQ2FybCBNb2JlcmcgYWxzbyBpbnRlZ3JhdGVkIHRoZSBjb25mZGMgb3V0cHV0IGlu
IGhpcyA8YSBocmVmPSJodHRwOi8vd3d3LnlhbmdhbGlkdG9yLmNvbSI+DQp3d3cueWFuZ2FsaWR0
b3IuY29tPC9hPi48YnI+DQpUaGlzIG1pZ2h0IGhlbHAgeW91Ljxicj4NCjxicj4NClJlZ2FyZHMs
IEJlbm9pdCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_CE7BEDB684E7430DB03EE2960D885D21junipernet_--


From nobody Sat Jul 16 12:00:24 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AC912D78F; Sat, 16 Jul 2016 12:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxGGwT7niSc4; Sat, 16 Jul 2016 12:00:21 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A7412D775; Sat, 16 Jul 2016 12:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8633; q=dns/txt; s=iport; t=1468695617; x=1469905217; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Cye9grEQ44BUkA8G3EZtGLqLIui2jJpCHeigX60YhuU=; b=b/6aHC2US4Xd83Gw/SBRqXNgK0IBdq3JbJLge++mcxQyFZ+BZnTzh5R3 NC1k8FYEHbav97wnkOM6kPhnF9BXKOmUvaT5IKmBTUj9O9w+oX/xH9qqw vR8Xpw9p0yLlVBLJEbYzJOAkhhbTJm6rUNge75xe2nCWJUxQjrbcZk96f 8=;
X-IronPort-AV: E=Sophos;i="5.28,375,1464652800";  d="scan'208,217";a="636766962"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 19:00:15 +0000
Received: from [10.61.161.254] ([10.61.161.254]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6GJ0EMX006849; Sat, 16 Jul 2016 19:00:15 GMT
To: Kent Watsen , "draft-ietf-netconf-server-model@ietf.org" , NETCONF 
References: <62b234e9-4402-0eb5-fd19-6786447395c3@cisco.com> 
From: Benoit Claise 
Message-ID: <2973f69f-1958-a8ca-126c-f7469cd3577c@cisco.com>
Date: Sat, 16 Jul 2016 21:00:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------935C789A50C2348A13F638BF"
Archived-At: 
Cc: "Carl Moberg \(camoberg\)" 
Subject: Re: [Netconf] draft-ietf-netconf-server-model-09.txt: confdc found some new errors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 19:00:23 -0000

This is a multi-part message in MIME format.
--------------935C789A50C2348A13F638BF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/16/2016 8:43 PM, Kent Watsen wrote:
>
> Hi Benoit,
>
> This particular draft is no longer an active WG document, as it has 
> been split into a number of other drafts now.  What needs to be done 
> to remove it from being scanned?
>
Use the "replaced-by" in the tracker
Btw, http://www.yangvalidator.com/

Regards, B.
>
> Thanks,
>
> Kent
>
> *From: *Benoit Claise 
> *Date: *Saturday, July 16, 2016 at 8:18 PM
> *To: *"draft-ietf-netconf-server-model@ietf.org" 
> , "netconf@ietf.org" 
> 
> *Cc: *"Carl Moberg (camoberg)" 
> *Subject: *draft-ietf-netconf-server-model-09.txt: confdc found some 
> new errors
> *Resent-From: *
> *Resent-To: *Kent Watsen , 
> 
> *Resent-Date: *Saturday, July 16, 2016 at 8:18 PM
>
> Dear authors,
>
>
> Part of the IETF hackathon today, I integrated confdc , as a second 
> YANG module compiler, in 
> http://www.claise.be/IETFYANGPageCompilation.html. Reason? For 
> example, confdc validates xpath while pyang doesn't.
> And confdc found an issue with your draft, which is now flagged as 
> failing the YANG compilation.
> Please correct this issue.
> Note: you're not alone, look at the green dip today on green graph 
> !
>
> During the hackathon today, Carl Moberg also integrated the confdc 
> output in his www.yangalidtor.com .
> This might help you.
>
> Regards, Benoit
>


--------------935C789A50C2348A13F638BF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/16/2016 8:43 PM, Kent Watsen
      wrote:

    

    

      
      
      
      
      
      

        
 

        
Hi Benoit,

        
 

        
This particular
            draft is no longer an active WG document, as it has been
            split into a number of other drafts now.  What needs to be
            done to remove it from being scanned?

      

    

    Use the "replaced-by" in the tracker

    Btw, http://www.yangvalidator.com/

    

    Regards, B.

    

      

        

        
 

        
Thanks,

        
Kent

        
 

        

          
From: 
            Benoit
              Claise <bclaise@cisco.com>

              Date: Saturday, July 16, 2016 at 8:18 PM

              To: "draft-ietf-netconf-server-model@ietf.org"
              <draft-ietf-netconf-server-model@ietf.org>,
              "netconf@ietf.org" <netconf@ietf.org>

              Cc: "Carl Moberg (camoberg)"
              <camoberg@cisco.com>

              Subject: draft-ietf-netconf-server-model-09.txt:
              confdc found some new errors

              Resent-From: <alias-bounces@ietf.org>

              Resent-To: Kent Watsen
              <kwatsen@juniper.net>,
              <j.schoenwaelder@jacobs-university.de>

              Resent-Date: Saturday, July 16, 2016 at 8:18 PM

        

        

          
 

        

        

          

            
Dear authors,

            

              


                Part of the IETF hackathon today, I integrated confdc ,
                as a second YANG module compiler, in
                http://www.claise.be/IETFYANGPageCompilation.html.
                Reason? For example, confdc validates xpath while pyang
                doesn't.

                And confdc found an issue with your draft, which is now
                flagged as failing the YANG compilation.

                Please correct this issue. 

                Note: you're not alone, look at 
                  the green dip today on green graph!

                

                During the hackathon today, Carl Moberg also integrated
                the confdc output in his 
                  www.yangalidtor.com.

                This might help you.

                

                Regards, Benoit 

            

            
 

          

        

      

    

    

  


--------------935C789A50C2348A13F638BF--


From nobody Sat Jul 16 14:56:40 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9312D16B; Sat, 16 Jul 2016 14:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nmEADf6eyI7; Sat, 16 Jul 2016 14:56:36 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14D412D112; Sat, 16 Jul 2016 14:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7281; q=dns/txt; s=iport; t=1468706196; x=1469915796; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=5bgKAdspPuGci7f0K00xC+y03aK1KBr97Z9K0w0R6lw=; b=gF5pjlbouDyb1gfDQ5LZxuuGpU8kOlDZHwGr8oHcGsbVouE7wTvqMkiN I3X8ZEWT6bf4X06Hx137HPmfdyN9f2SqxSEw5UNbGab6qRH6t9DHzhY+e BoPVBwM1c1c2hE0WIQEXhfYjyMJ9OwO+Bpry+nJjp+OvBnJ9hPlmOKqf/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjDAAsrYpX/xbLJq1cgnGBTlKsWocXh?= =?us-ascii?q?n2GGgKBcwEBAQEBAWYnhF0BBSNWEAsYJwMCAiElEQYBDAYCAQGIEgMXsCqJLQ2?= =?us-ascii?q?EHgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoF4glWCQ4R+gloBBJhwNIxEghuJU?= =?us-ascii?q?IVniCWHeVSDdToyh2gBAQE?=
X-IronPort-AV: E=Sophos;i="5.28,375,1464652800";  d="scan'208,217";a="636768018"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 21:56:10 +0000
Received: from [10.61.161.254] ([10.61.161.254]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6GLuAlg027988; Sat, 16 Jul 2016 21:56:10 GMT
To: Andy Bierman , Mahesh Jethanandani 
References: <23751ecb-3b32-caab-8a3f-3f2846b8a4f7@cisco.com> <9b36aa58-de5c-b72e-ce3d-08bf1b8c582d@cisco.com> <913421AD-60EE-4980-89BE-F2BB1567DE5F@gmail.com>   
From: Benoit Claise 
Message-ID: <69191cf7-e0d7-4bb6-34e4-d8514e258151@cisco.com>
Date: Sat, 16 Jul 2016 23:56:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------BC49D761265FB2C7C46F82AB"
Archived-At: 
Cc: "draft-ietf-netconf-yang-patch@ietf.org" , NETCONF 
Subject: Re: [Netconf] AD review: draft-ietf-netconf-yang-patch-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jul 2016 21:56:38 -0000

This is a multi-part message in MIME format.
--------------BC49D761265FB2C7C46F82AB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

It would be nice to make it clear.
Maybe I overlooked that statement in the draft.

Regards, B.
> Hi,
>
> YANG Patch does not replace the entire datastore.
> If the target resource is the datastore then each edit target
> is relative to the datastore root.
>
>
> Andy
>
>
> On Tue, Jul 12, 2016 at 1:44 PM, Mahesh Jethanandani 
> > wrote:
>
>     Ok. We seem to agree that  cannot be used to replace
>     or delete an entire configuration.
>
>     Though the discussion was in the context of NETCONF, I would
>     venture to say the same would apply to RESTCONF and YANG Patch also.
>
>     So the following statement:
>
>>
>>     And, in section 2.1
>>
>>        This can be the
>>        datastore resource itself, i.e., "{+restconf}/data", or it can
>>     be a
>>        configuration data resource within the datastore resource, e.g.,
>>        {+restconf/data/ietf-interfaces:interfaces".
>>
>
>     where we are referencing the entire datastore “{+restconf}/dataâ€
>     seems to imply that the entire data store can be replaced or
>     deleted using edit operations is not correct.
>
>     Does anyone disagree?
>
>     Mahesh Jethanandani
>     mjethanandani@gmail.com 
>
>
>
>


--------------BC49D761265FB2C7C46F82AB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

      

      It would be nice to make it clear.

      Maybe I overlooked that statement in the draft.

      

      Regards, B.

    

    

      
      
Hi,
        


        

        
YANG Patch does not replace the entire datastore.

        
If the target resource is the datastore then each edit
          target

        
is relative to the datastore root.

      

    

    

      

        


        

        


        

        
Andy

        


        

      

      


        
On Tue, Jul 12, 2016 at 1:44 PM, Mahesh
          Jethanandani <mjethanandani@gmail.com>
          wrote:

          

            
Ok. We seem to agree that
              <edit-config> cannot be used to replace or delete an
              entire configuration. 
              


              

              
Though the discussion was in the context of NETCONF,
                I would venture to say the same would apply to RESTCONF
                and YANG Patch also.
                


                

                
So the following statement:

                


                  

                    


                      

                        
And,
                            in section 2.1

                            

                          

                        
   This can be the

                        
   datastore resource itself, i.e., "{+restconf}/data", or it can be a

                        
   configuration data resource within the datastore resource, e.g.,

                        
   {+restconf/data/ietf-interfaces:interfaces".

                        

                      

                    

                  

                  


                  

                  where we are referencing the entire datastore
                  “{+restconf}/data†seems to imply that the entire data
                  store can be replaced or deleted using edit operations
                  is not correct.

                


                

                
Does anyone disagree?

                
                    


                      

                        
Mahesh Jethanandani

                        
                        


                        

                        

                      

                      

                    

                  

            

          

        

        

      

    

    

  


--------------BC49D761265FB2C7C46F82AB--


From nobody Sun Jul 17 03:34:31 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1EF12D580; Sun, 17 Jul 2016 03:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhfRHcBhfJTB; Sun, 17 Jul 2016 03:34:26 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6872812D1A3; Sun, 17 Jul 2016 03:34:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6BcKCEuM9k1a0eeycq6JgHJI+oOI8LVEytKfOD1+HNs=; b=OCjD/Z3WT4QKJd1ppfkmyYUOtkIg8Mp/wDkoHkyt8Klv7Vuhj5T0GLZPl+/FlfYzk98HWZCh1fGunNy79UdaXgg1jvm8LYPSgMpTc7juXIUG0mHQEBjsfF0sHB7A51LpAzStURwrv8NNiESDE1MVdcRPAAYtTesY2VTYoC03X60=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.528.16; Sun, 17 Jul 2016 10:34:21 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0549.003; Sun, 17 Jul 2016 10:34:20 +0000
From: Kent Watsen 
To: Benoit Claise , "draft-ietf-netconf-zerotouch@ietf.org" , NETCONF 
Thread-Topic: draft-ietf-netconf-zerotouch-09.txt: new error from confdc
Thread-Index: AQHR349zf4Xdx3NX3Ua1cjuwKZElGqAcK2AA
Date: Sun, 17 Jul 2016 10:34:20 +0000
Message-ID: <67EB6669-F17F-412D-AC14-6223F5BAEA37@juniper.net>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.17.0.160611
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [31.133.177.40]
x-ms-office365-filtering-correlation-id: 767119c6-fb21-4292-ff55-08d3ae2de9db
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:J+KwC7oHrooejVo32Vk4/RaiQUB2k9eQQgjIRnHBtvZ3qzJbah+mLT1lDy75KtKe4+hY+y2rsyDjIrVqtfb1tXKX20f8f2StwG6ThmxC5eKcQTpDo2y87wD8GW0Qut8f205wrp+GMFWeD3RT8txfnXYbDA+QZxrgGW7Smp55rLVBUn/4MOq4Uzh6Rey8nx1LLnv3GqcNvlG/WlQbpupugYEvwieFmLkseIe0lsEP6Mcod8p0JU2Ib8eXtSqppWmAjdk97w1KbE8mJ0e0jXWjtVeOJgVFmrelJ2HsRb303XRc69FrfjgaJG2jurpOz8dZ8eNHtQ0pqsLcfoWMmfXM7g==; 5:8AV2LR/dy26Uappa+b9e0xP9fgU0toDebSnB9bNWMIi3JUoDzqMva3O59+dFZ6MyvPHPBK2Xvpv0mrfmox9iy7+yPrdgAHtpNyjTUaOPTwXdnlTy4KhIhYiGhqKq8Bp8x0BhStbUvHQg3Uw6bt7hpA==; 24:yaIY9zaeOYAuXd3HOyNJdmsS41Xg/p2b2uhMyEbf+Q2vzXOYCTkKBJR35+85w3IOzsoBMrssQw1amRiucobw0S8pf/vKh7cXQ9vLfvTY/FE=; 7:KxzmT9UqeIDoLzHBTgR+kIWPkNLgKPw9kTpciFHafzHCRJmra+9ATxLDPK8RH6aeLUZoPTksDcpdHX3XDVkmHTKPXUyDs8VxzgjhA8lGqTX+bG7lm1DTBo5G38/5vlKNGHgLdNi98tXl85VtnuIMHg7j1xm9rnYXGaKo5aV4BF41j/SUj50iHM5/Pc8I1Dcp/ViDbmdWbSXNH0L+mwj6IoOzOltEighD0udGoGLCPbhMsVfgbr7KXnG4mqSu8VCL
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);  SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 00064751B6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(51914003)(99286002)(1680700002)(86362001)(105586002)(189998001)(54356999)(97736004)(50986999)(92566002)(106116001)(5001770100001)(82746002)(4001350100001)(77096005)(2900100001)(122556002)(10400500002)(3660700001)(83716003)(66066001)(19617315012)(5002640100001)(2950100001)(16601075003)(33656002)(2906002)(102836003)(68736007)(81166006)(76176999)(106356001)(8936002)(9326002)(81156014)(15975445007)(36756003)(3280700002)(83506001)(19300405004)(16236675004)(586003)(3846002)(19625215002)(15395725005)(6116002)(87936001)(7736002)(8676002)(19580405001)(2501003)(19580395003)(14971765001)(7846002)(101416001)(230783001)(107886002)(7906003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_67EB6669F17F412DAC146223F5BAEA37junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2016 10:34:20.8701 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jul 2016 10:34:29 -0000

--_000_67EB6669F17F412DAC146223F5BAEA37junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQmVub2l0LA0KDQpUaGFua3MgZm9yIHRoZSByZXBvcnQuICAgRm9yIHRoaXMgaXRlbSwgQ29u
ZmRjIGZvdW5kIG9uZSBpc3N1ZToNCg0KICAgICAgICBpZXRmLXplcm90b3VjaC1ib290c3RyYXAt
c2VydmVyQDIwMTYtMDctMDgueWFuZzoyNTY6IGVycm9yOiB1bmV4cGVjdGVkIGtleXdvcmQgJ211
c3QnDQoNCkhlcmUgaXMgdGhlIGxpbmUgaW4gcXVlc3Rpb246DQoNCiAgICAgICAgICBhbnl4bWwg
Y29uZmlndXJhdGlvbiB7IC8vIHB5YW5nIHZhbGlkYXRpb24gZG9lc24ndCBzdXBwb3J0IGFueWRh
dGEgeWV0DQogICAgICAgICAgICBtdXN0ICIuLi9jb25maWd1cmF0aW9uLWhhbmRsaW5nIjsNCiAg
ICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICJBbnkgY29uZmlndXJhdGlvbiBk
YXRhIG1vZGVsIGtub3duIHRvIHRoZSBkZXZpY2UuICBJdCBtYXkNCiAgICAgICAgICAgICAgIGNv
bnRhaW4gbWFudWZhY3R1cmVyLXNwZWNpZmljIGFuZC9vciBzdGFuZGFyZHMtYmFzZWQgZGF0YQ0K
ICAgICAgICAgICAgICAgbW9kZWxzLiI7DQogICAgICAgICB9DQoNCkZyb20gNjAyMGJpcywgdGhl
IEFCTkYgaXM6DQoNCiAgIGFueXhtbC1zdG10ICAgICAgICAgPSBhbnl4bWwta2V5d29yZCBzZXAg
aWRlbnRpZmllci1hcmctc3RyIG9wdHNlcA0KICAgICAgICAgICAgICAgICAgICAgICAgICgiOyIg
Lw0KICAgICAgICAgICAgICAgICAgICAgICAgICAieyIgc3RtdHNlcA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgOzsgdGhlc2Ugc3RtdHMgY2FuIGFwcGVhciBpbiBhbnkgb3JkZXINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFt3aGVuLXN0bXRdDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAqaWYtZmVhdHVyZS1zdG10DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAqbXVzdC1zdG10DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbY29uZmlnLXN0
bXRdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbbWFuZGF0b3J5LXN0bXRdDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBbc3RhdHVzLXN0bXRdDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBbZGVzY3JpcHRpb24tc3RtdF0NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFtyZWZlcmVuY2Utc3RtdF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICJ9Iikg
c3RtdHNlcA0KDQoNCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGlzIHNob3VsZCBiZSB2YWxpZCBZ
QU5HLg0KDQpQUzogSSB3b3VsZCByYXRoZXIgYmUgdXNpbmcgYW55ZGF0YSAobm90IGFueXhtbCkg
YnV0LCBhcyB0aGUgY29tbWVudCBhYm92ZSBtZW50aW9ucywgcHlhbmcgdmFsaWRhdGlvbiAoZS5n
LiwgeWFuZzJkc2RsKSBkb2VzbuKAmXQgc3VwcG9ydCBZQU5HIDEuMSBzdGF0ZW1lbnRzIHlldCwg
c28gSeKAmW0gdGVtcG9yYXJpbHkgdXNpbmcgYW55eG1sLi4uDQoNCnlhbmcyZHNkbCAtdCBkYXRh
IGlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXJcQDIwMTYtMDctMTcueWFuZw0KVW5rbm93
biBrZXl3b3JkIGFueWRhdGEgLSB0aGlzIHNob3VsZCBub3QgaGFwcGVuLg0KDQoNClRoYW5rcywN
CktlbnQNCg0KDQpGcm9tOiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCkRhdGU6
IFNhdHVyZGF5LCBKdWx5IDE2LCAyMDE2IGF0IDg6MjUgUE0NClRvOiAiZHJhZnQtaWV0Zi1uZXRj
b25mLXplcm90b3VjaEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtbmV0Y29uZi16ZXJvdG91Y2hAaWV0
Zi5vcmc+LCAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBk
cmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA5LnR4dDogbmV3IGVycm9yIGZyb20gY29uZmRj
DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IEtlbnQg
V2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiwgPCJtaWthZWwuYWJyYWhhbXNzb25AdC1zeXN0
ZW1zLnNlIkBpZXRmYS5hbXNsLmNvbT4NClJlc2VudC1EYXRlOiBTYXR1cmRheSwgSnVseSAxNiwg
MjAxNiBhdCA4OjI1IFBNDQoNCkRlYXIgYXV0aG9ycywNCg0KUGFydCBvZiB0aGUgSUVURiBoYWNr
YXRob24gdG9kYXksIEkgaW50ZWdyYXRlZCBjb25mZGMgLCBhcyBhIHNlY29uZCBZQU5HIG1vZHVs
ZSBjb21waWxlciwgaW4gaHR0cDovL3d3dy5jbGFpc2UuYmUvSUVURllBTkdQYWdlQ29tcGlsYXRp
b24uaHRtbC4gUmVhc29uPyBGb3IgZXhhbXBsZSwgY29uZmRjIHZhbGlkYXRlcyB4cGF0aCB3aGls
ZSBweWFuZyBkb2Vzbid0Lg0KQW5kIGNvbmZkYyBmb3VuZCBhbiBpc3N1ZSB3aXRoIHlvdXIgZHJh
ZnQsIHdoaWNoIGlzIG5vdyBmbGFnZ2VkIGFzIGZhaWxpbmcgdGhlIFlBTkcgY29tcGlsYXRpb24u
DQpQbGVhc2UgY29ycmVjdCB0aGlzIGlzc3VlLg0KTm90ZTogeW91J3JlIG5vdCBhbG9uZSwgbG9v
ayBhdCB0aGUgZ3JlZW4gZGlwIHRvZGF5IG9uIGdyZWVuIGdyYXBoPGh0dHA6Ly9jbGFpc2UuYmUv
SUVURllBTkdQYWdlQ29tcGlsYXRpb24ucG5nPiENCg0KRHVyaW5nIHRoZSBoYWNrYXRob24gdG9k
YXksIENhcmwgTW9iZXJnIGFsc28gaW50ZWdyYXRlZCB0aGUgY29uZmRjIG91dHB1dCBpbiBoaXMg
d3d3LnlhbmdhbGlkdG9yLmNvbTxodHRwOi8vd3d3LnlhbmdhbGlkdG9yLmNvbT4uDQpUaGlzIG1p
Z2h0IGhlbHAgeW91Lg0KDQpSZWdhcmRzLCBCZW5vaXQNCg==

--_000_67EB6669F17F412DAC146223F5BAEA37junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <1226EEA42DC9E74D8E9106CB23699070@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MgZm9y
IHRoZSByZXBvcnQuJm5ic3A7Jm5ic3A7IEZvciB0aGlzIGl0ZW0sIENvbmZkYyBmb3VuZCBvbmUg
aXNzdWU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlldGYtemVyb3RvdWNo
LWJvb3RzdHJhcC1zZXJ2ZXJAMjAxNi0wNy0wOC55YW5nOjI1NjogZXJyb3I6IHVuZXhwZWN0ZWQg
a2V5d29yZCAnbXVzdCc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IZXJlIGlzIHRoZSBsaW5l
IGluIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBhbnl4bWwgY29uZmlndXJhdGlvbiB7IC8vIHB5YW5nIHZhbGlkYXRpb24gZG9lc24ndCBz
dXBwb3J0IGFueWRhdGEgeWV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11c3QgJnF1b3Q7Li4vY29uZmlndXJh
dGlvbi1oYW5kbGluZyZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7QW55IGNvbmZpZ3VyYXRpb24gZGF0YSBtb2RlbCBrbm93
biB0byB0aGUgZGV2aWNlLiZuYnNwOyBJdCBtYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgY29udGFpbiBtYW51ZmFjdHVyZXItc3BlY2lmaWMgYW5kL29yIHN0YW5kYXJkcy1iYXNl
ZCBkYXRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vZGVscy4mcXVvdDs7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkZyb20gNjAyMGJpcywgdGhlIEFCTkYgaXM6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5i
c3A7IGFueXhtbC1zdG10Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7ID0gYW55eG1sLWtleXdvcmQgc2VwIGlkZW50aWZpZXItYXJnLXN0ciBvcHRzZXA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKCZxdW90OzsmcXVvdDsgLzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt7JnF1b3Q7IHN0bXRzZXA8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgOzsgdGhlc2Ugc3RtdHMgY2FuIGFwcGVhciBpbiBhbnkgb3JkZXI8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
W3doZW4tc3RtdF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgKmlmLWZlYXR1cmUtc3RtdDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqbXVzdC1zdG10
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IFtjb25maWctc3RtdF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW21hbmRhdG9yeS1zdG10XTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBbc3RhdHVzLXN0bXRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtkZXNjcmlwdGlvbi1zdG10XTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbcmVm
ZXJlbmNlLXN0bXRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICZxdW90O30mcXVvdDspIHN0bXRzZXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BcyBmYXIgYXMgSSBjYW4g
dGVsbCwgdGhpcyBzaG91bGQgYmUgdmFsaWQgWUFORy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij5QUzogSSB3b3VsZCByYXRoZXIgYmUgdXNpbmcgYW55ZGF0YSAobm90IGFueXhtbCkgYnV0LCBh
cyB0aGUgY29tbWVudCBhYm92ZSBtZW50aW9ucywgcHlhbmcgdmFsaWRhdGlvbiAoZS5nLiwgeWFu
ZzJkc2RsKSBkb2VzbuKAmXQgc3VwcG9ydCBZQU5HIDEuMSBzdGF0ZW1lbnRzIHlldCwgc28gSeKA
mW0gdGVtcG9yYXJpbHkgdXNpbmcNCiBhbnl4bWwuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj55YW5nMmRzZGwgLXQgZGF0YSBpZXRmLXplcm90b3Vj
aC1ib290c3RyYXAtc2VydmVyXEAyMDE2LTA3LTE3LnlhbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlVua25vd24ga2V5d29y
ZCBhbnlkYXRhIC0gdGhpcyBzaG91bGQgbm90IGhhcHBlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3Ms
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkJlbm9pdCBDbGFpc2UgJmx0O2JjbGFp
c2VAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgSnVseSAxNiwgMjAx
NiBhdCA4OjI1IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtkcmFmdC1pZXRmLW5ldGNvbmYtemVy
b3RvdWNoQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoQGll
dGYub3JnJmd0OywgJnF1b3Q7bmV0Y29uZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRm
Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3Vj
aC0wOS50eHQ6IG5ldyBlcnJvciBmcm9tIGNvbmZkYzxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+
Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+S2Vu
dCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7LCAmbHQ7JnF1b3Q7bWlrYWVsLmFi
cmFoYW1zc29uQHQtc3lzdGVtcy5zZSZxdW90O0BpZXRmYS5hbXNsLmNvbSZndDs8YnI+DQo8Yj5S
ZXNlbnQtRGF0ZTogPC9iPlNhdHVyZGF5LCBKdWx5IDE2LCAyMDE2IGF0IDg6MjUgUE08bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5EZWFyIGF1dGhvcnMsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NClBhcnQgb2YgdGhlIElFVEYgaGFja2F0aG9uIHRvZGF5LCBJIGludGVncmF0
ZWQgY29uZmRjICwgYXMgYSBzZWNvbmQgWUFORyBtb2R1bGUgY29tcGlsZXIsIGluDQo8YSBocmVm
PSJodHRwOi8vd3d3LmNsYWlzZS5iZS9JRVRGWUFOR1BhZ2VDb21waWxhdGlvbi5odG1sIj5odHRw
Oi8vd3d3LmNsYWlzZS5iZS9JRVRGWUFOR1BhZ2VDb21waWxhdGlvbi5odG1sPC9hPi4gUmVhc29u
PyBGb3IgZXhhbXBsZSwgY29uZmRjIHZhbGlkYXRlcyB4cGF0aCB3aGlsZSBweWFuZyBkb2Vzbid0
Ljxicj4NCkFuZCBjb25mZGMgZm91bmQgYW4gaXNzdWUgd2l0aCB5b3VyIGRyYWZ0LCB3aGljaCBp
cyBub3cgZmxhZ2dlZCBhcyBmYWlsaW5nIHRoZSBZQU5HIGNvbXBpbGF0aW9uLjxicj4NClBsZWFz
ZSBjb3JyZWN0IHRoaXMgaXNzdWUuIDxicj4NCk5vdGU6IHlvdSdyZSBub3QgYWxvbmUsIGxvb2sg
YXQgPGEgaHJlZj0iaHR0cDovL2NsYWlzZS5iZS9JRVRGWUFOR1BhZ2VDb21waWxhdGlvbi5wbmci
Pg0KdGhlIGdyZWVuIGRpcCB0b2RheSBvbiBncmVlbiBncmFwaDwvYT4hPGJyPg0KPGJyPg0KRHVy
aW5nIHRoZSBoYWNrYXRob24gdG9kYXksIENhcmwgTW9iZXJnIGFsc28gaW50ZWdyYXRlZCB0aGUg
Y29uZmRjIG91dHB1dCBpbiBoaXMgPGEgaHJlZj0iaHR0cDovL3d3dy55YW5nYWxpZHRvci5jb20i
Pg0Kd3d3LnlhbmdhbGlkdG9yLmNvbTwvYT4uPGJyPg0KVGhpcyBtaWdodCBoZWxwIHlvdS48YnI+
DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_67EB6669F17F412DAC146223F5BAEA37junipernet_--


From nobody Sun Jul 17 16:32:47 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27912B00D for ; Sun, 17 Jul 2016 16:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.891
X-Spam-Level: 
X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 uQfZ1cjfeJYP for ; Sun, 17 Jul 2016 16:32:44 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B46712B009 for ; Sun, 17 Jul 2016 16:32:44 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id F2D485CD1C2AC; Sun, 17 Jul 2016 23:32:37 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u6HNWg7r017557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Jul 2016 23:32:42 GMT
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u6HNWgxo020213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Jul 2016 23:32:42 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 17 Jul 2016 19:32:42 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Benoit Claise , NETCONF 
Thread-Topic: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
Thread-Index: AQHR34913APyhe0gV0mGqCb7fciCfKAdR4iA
Date: Sun, 17 Jul 2016 23:32:41 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCCC329US70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jul 2016 23:32:46 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCCC329US70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQmVub2l0LA0KDQpJIHRoaW5rIHlvdXIgbGluayBpcyBhIGJpdCBicm9rZW4gYmVsb3cgKGZv
ciB5YW5ndmFsaWRhdG9yLmNvbSkuDQoNCklzIGNvbmZkYyBhdmFpbGFibGUgYXMgYSBzdGFuZGFs
b25lIHRvb2wgPyAgSSB0b29rIGEgcXVpY2sgbG9vayBhcm91bmQgYnV0IGRpZG7igJl0IGZpbmQg
aXQuDQoNCkphc29uDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW5vaXQgQ2xhaXNlDQpTZW50OiBTYXR1cmRheSwgSnVseSAx
NiwgMjAxNiAxNDoyNg0KVG86IGRyYWZ0LWlldGYtbmV0Y29uZi16ZXJvdG91Y2hAaWV0Zi5vcmc7
IE5FVENPTkYNClN1YmplY3Q6IFtOZXRjb25mXSBkcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNo
LTA5LnR4dDogbmV3IGVycm9yIGZyb20gY29uZmRjDQoNCkRlYXIgYXV0aG9ycywNCg0KUGFydCBv
ZiB0aGUgSUVURiBoYWNrYXRob24gdG9kYXksIEkgaW50ZWdyYXRlZCBjb25mZGMgLCBhcyBhIHNl
Y29uZCBZQU5HIG1vZHVsZSBjb21waWxlciwgaW4gaHR0cDovL3d3dy5jbGFpc2UuYmUvSUVURllB
TkdQYWdlQ29tcGlsYXRpb24uaHRtbC4gUmVhc29uPyBGb3IgZXhhbXBsZSwgY29uZmRjIHZhbGlk
YXRlcyB4cGF0aCB3aGlsZSBweWFuZyBkb2Vzbid0Lg0KQW5kIGNvbmZkYyBmb3VuZCBhbiBpc3N1
ZSB3aXRoIHlvdXIgZHJhZnQsIHdoaWNoIGlzIG5vdyBmbGFnZ2VkIGFzIGZhaWxpbmcgdGhlIFlB
TkcgY29tcGlsYXRpb24uDQpQbGVhc2UgY29ycmVjdCB0aGlzIGlzc3VlLg0KTm90ZTogeW91J3Jl
IG5vdCBhbG9uZSwgbG9vayBhdCB0aGUgZ3JlZW4gZGlwIHRvZGF5IG9uIGdyZWVuIGdyYXBoPGh0
dHA6Ly9jbGFpc2UuYmUvSUVURllBTkdQYWdlQ29tcGlsYXRpb24ucG5nPiENCg0KRHVyaW5nIHRo
ZSBoYWNrYXRob24gdG9kYXksIENhcmwgTW9iZXJnIGFsc28gaW50ZWdyYXRlZCB0aGUgY29uZmRj
IG91dHB1dCBpbiBoaXMgd3d3LnlhbmdhbGlkdG9yLmNvbTxodHRwOi8vd3d3LnlhbmdhbGlkdG9y
LmNvbT4uDQpUaGlzIG1pZ2h0IGhlbHAgeW91Lg0KDQpSZWdhcmRzLCBCZW5vaXQNCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCCC329US70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5IaSBCZW5vaXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHlvdXIgbGluayBp
cyBhIGJpdCBicm9rZW4gYmVsb3cgKGZvciB5YW5ndmFsaWRhdG9yLmNvbSkuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
cyBjb25mZGMgYXZhaWxhYmxlIGFzIGEgc3RhbmRhbG9uZSB0b29sID8mbmJzcDsgSSB0b29rIGEg
cXVpY2sgbG9vayBhcm91bmQgYnV0IGRpZG7igJl0IGZpbmQgaXQuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KYXNvbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBOZXRj
b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5CZW5vaXQgQ2xhaXNlPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKdWx5IDE2LCAyMDE2
IDE0OjI2PGJyPg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoQGlldGYu
b3JnOyBORVRDT05GPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtOZXRjb25mXSBkcmFmdC1pZXRmLW5l
dGNvbmYtemVyb3RvdWNoLTA5LnR4dDogbmV3IGVycm9yIGZyb20gY29uZmRjPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhdXRob3JzLCA8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpQYXJ0IG9mIHRoZSBJ
RVRGIGhhY2thdGhvbiB0b2RheSwgSSBpbnRlZ3JhdGVkIGNvbmZkYyAsIGFzIGEgc2Vjb25kIFlB
TkcgbW9kdWxlIGNvbXBpbGVyLCBpbg0KPGEgaHJlZj0iaHR0cDovL3d3dy5jbGFpc2UuYmUvSUVU
RllBTkdQYWdlQ29tcGlsYXRpb24uaHRtbCI+aHR0cDovL3d3dy5jbGFpc2UuYmUvSUVURllBTkdQ
YWdlQ29tcGlsYXRpb24uaHRtbDwvYT4uIFJlYXNvbj8gRm9yIGV4YW1wbGUsIGNvbmZkYyB2YWxp
ZGF0ZXMgeHBhdGggd2hpbGUgcHlhbmcgZG9lc24ndC48YnI+DQpBbmQgY29uZmRjIGZvdW5kIGFu
IGlzc3VlIHdpdGggeW91ciBkcmFmdCwgd2hpY2ggaXMgbm93IGZsYWdnZWQgYXMgZmFpbGluZyB0
aGUgWUFORyBjb21waWxhdGlvbi48YnI+DQpQbGVhc2UgY29ycmVjdCB0aGlzIGlzc3VlLiA8YnI+
DQpOb3RlOiB5b3UncmUgbm90IGFsb25lLCBsb29rIGF0IDxhIGhyZWY9Imh0dHA6Ly9jbGFpc2Uu
YmUvSUVURllBTkdQYWdlQ29tcGlsYXRpb24ucG5nIj4NCnRoZSBncmVlbiBkaXAgdG9kYXkgb24g
Z3JlZW4gZ3JhcGg8L2E+ITxicj4NCjxicj4NCkR1cmluZyB0aGUgaGFja2F0aG9uIHRvZGF5LCBD
YXJsIE1vYmVyZyBhbHNvIGludGVncmF0ZWQgdGhlIGNvbmZkYyBvdXRwdXQgaW4gaGlzIDxhIGhy
ZWY9Imh0dHA6Ly93d3cueWFuZ2FsaWR0b3IuY29tIj4NCnd3dy55YW5nYWxpZHRvci5jb208L2E+
Ljxicj4NClRoaXMgbWlnaHQgaGVscCB5b3UuPGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0IDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_A125E53CE190A749957C19483DC79F9F5CCCC329US70TWXCHMBA11z_--


From nobody Sun Jul 17 16:36:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713C212B00E for ; Sun, 17 Jul 2016 16:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.797
X-Spam-Level: 
X-Spam-Status: No, score=-15.797 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glj-OZA-t9tm for ; Sun, 17 Jul 2016 16:36:08 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B0B12B009 for ; Sun, 17 Jul 2016 16:36:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8129; q=dns/txt; s=iport; t=1468798568; x=1470008168; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=oWQtoKlHsy+4ykGmtRBE3eCFoB6UKsZl1vtDcmGAyAo=; b=k4hONlwdfws4tsDhD8Ma7cq9v8FA6qKTjTjaweDkkF3+AqopB7NON9/c +BzqpIAucO+zko1iIvCFEecvP+a95ZiZmNbLGGNt1vPNqh257fK5sRZY7 hyV4hzHYMzBkvhptpZWLad7AINrUst4zjPX9HYnBRyYTMnphi5oBw0r+b 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKFQBlFYxX/xbLJq1bgnGBJCpSs3aGf?= =?us-ascii?q?SKFeAKBbgEBAQEBAWYnhFwBAQUjChxACwcKBAEBKAMCAkYJCAYBDAYCAQGILA6?= =?us-ascii?q?xAo1bAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYqgXiCVYR2gkuCWgWZJIYTiEyBa?= =?us-ascii?q?06EC4MMhWeQHlSDdToyAYV2K4EXAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,381,1464652800";  d="scan'208,217";a="636782049"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2016 23:36:05 +0000
Received: from [10.61.162.48] ([10.61.162.48]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6HNa5tO000384; Sun, 17 Jul 2016 23:36:05 GMT
To: "Sterne, Jason (Nokia - CA)" , NETCONF 
References:  
From: Benoit Claise 
Message-ID: <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com>
Date: Mon, 18 Jul 2016 01:36:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------20A0E4CC1B4B3AE49EE4C880"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jul 2016 23:36:10 -0000

This is a multi-part message in MIME format.
--------------20A0E4CC1B4B3AE49EE4C880
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jason,
>
> Hi Benoit,
>
> I think your link is a bit broken below (for yangvalidator.com).
>
http://www.yangvalidator.com/
>
> Is confdc available as a standalone tool ?  I took a quick look around 
> but didn’t find it.
>
https://developer.cisco.com/site/confD/downloads/

Regards, B.
>
> Jason
>
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Benoit 
> Claise
> *Sent:* Saturday, July 16, 2016 14:26
> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error 
> from confdc
>
> Dear authors,
>
>
> Part of the IETF hackathon today, I integrated confdc , as a second 
> YANG module compiler, in 
> http://www.claise.be/IETFYANGPageCompilation.html. Reason? For 
> example, confdc validates xpath while pyang doesn't.
> And confdc found an issue with your draft, which is now flagged as 
> failing the YANG compilation.
> Please correct this issue.
> Note: you're not alone, look at the green dip today on green graph 
> !
>
> During the hackathon today, Carl Moberg also integrated the confdc 
> output in his www.yangalidtor.com .
> This might help you.
>
> Regards, Benoit
>


--------------20A0E4CC1B4B3AE49EE4C880
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Jason,

    

    

      
      
      
      

        
Hi
            Benoit,

        
 

        
I
            think your link is a bit broken below (for
            yangvalidator.com).

      

    

    http://www.yangvalidator.com/

    

      

        

        
 

        
Is
            confdc available as a standalone tool ?  I took a quick look
            around but didn’t find it.

      

    

    https://developer.cisco.com/site/confD/downloads/

    

    Regards, B.

    

      

        

        
 

        
Jason

        
 

        

          

            
From:
                Netconf [mailto:netconf-bounces@ietf.org]
                On Behalf Of Benoit Claise

                Sent: Saturday, July 16, 2016 14:26

                To: draft-ietf-netconf-zerotouch@ietf.org;
                NETCONF

                Subject: [Netconf]
                draft-ietf-netconf-zerotouch-09.txt: new error from
                confdc

          

        

        
 

        
Dear authors, 

        

          


            Part of the IETF hackathon today, I integrated confdc , as a
            second YANG module compiler, in
            http://www.claise.be/IETFYANGPageCompilation.html.
            Reason? For example, confdc validates xpath while pyang
            doesn't.

            And confdc found an issue with your draft, which is now
            flagged as failing the YANG compilation.

            Please correct this issue. 

            Note: you're not alone, look at 
              the green dip today on green graph!

            

            During the hackathon today, Carl Moberg also integrated the
            confdc output in his 
              www.yangalidtor.com.

            This might help you.

            

            Regards, Benoit 

        

      

    

    

  


--------------20A0E4CC1B4B3AE49EE4C880--


From nobody Mon Jul 18 02:51:22 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B731E12D61C for ; Mon, 18 Jul 2016 02:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZRQzMzDaquaa for ; Mon, 18 Jul 2016 02:51:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7712D7F4 for ; Mon, 18 Jul 2016 02:48:26 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id B566B1AE039A; Mon, 18 Jul 2016 11:48:23 +0200 (CEST)
To: Benoit Claise 
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com>
From: Per Hedeland 
Message-ID: <578CA5E7.6050906@tail-f.com>
Date: Mon, 18 Jul 2016 11:48:23 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 09:51:20 -0000

On 2016-07-18 01:36, Benoit Claise wrote:
> Hi Jason,
>>
>> Hi Benoit,
>>
>> I think your link is a bit broken below (for yangvalidator.com).
>>
> http://www.yangvalidator.com/
>>
>> Is confdc available as a standalone tool ?  I took a quick look around but didnt find it.
>>
> https://developer.cisco.com/site/confD/downloads/

Well, not exactly "standalone" I guess... But anyway, for the purpose of
YANG validation, I would suggest that 'yanger' is a more appropriate
tool than 'confdc' - 'yanger' is "An extensible YANG validator and
converter" just like pyang, though not written in Python. confdc used to
use pyang "under the cover", but nowadays uses yanger instead.

Using yanger directly instead of via confdc will avoid getting reports
of tail-f-specific "errors" like "cannot compile submodules; compile the
module instead" or "cannot compile modules with top-level choices", and
will also avoid spending cycles on littering your file system with .fxs
files that are of no use in this context.

When using a ConfD installation per above, 'yanger' will be in your $PATH
just like 'confdc' - it doesn't have any actual documentation yet, but
invoking 'yanger -h' will give a usage summary. Typically you only need
to run 'yanger ' though.

--Per

> Regards, B.
> 
>> Jason
>>
>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Benoit Claise
>> *Sent:* Saturday, July 16, 2016 14:26
>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
>>
>> Dear authors,
>>
>>
>> Part of the IETF hackathon today, I integrated confdc , as a second YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. Reason? For example, confdc validates xpath while
>> pyang doesn't.
>> And confdc found an issue with your draft, which is now flagged as failing the YANG compilation.
>> Please correct this issue.
>> Note: you're not alone, look at the green dip today on green graph !
>>
>> During the hackathon today, Carl Moberg also integrated the confdc output in his www.yangalidtor.com .
>> This might help you.
>>
>> Regards, Benoit
>>
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Mon Jul 18 03:16:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A2612D7A1; Mon, 18 Jul 2016 03:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CWtrUyEATHXk; Mon, 18 Jul 2016 03:16:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 340AA12D7D1; Mon, 18 Jul 2016 03:15:50 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DEE11AE039A; Mon, 18 Jul 2016 12:15:49 +0200 (CEST)
To: Kent Watsen 
References:  <67EB6669-F17F-412D-AC14-6223F5BAEA37@juniper.net>
From: Per Hedeland 
Message-ID: <578CAC54.5080607@tail-f.com>
Date: Mon, 18 Jul 2016 12:15:48 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <67EB6669-F17F-412D-AC14-6223F5BAEA37@juniper.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "draft-ietf-netconf-zerotouch@ietf.org" , NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 10:16:08 -0000

Hi Kent,

This is clearly a bug in confdc, or rather in the 'yanger' validator
that it uses (see my previous message to netconf@) - will be fixed in an
upcoming release. (And FWIW, it has the same bug for anydata - will also
be fixed of course.) And unfortunately a "grammatical" error (even if
wrong:-) will terminate the analysis.

--Per

On 2016-07-17 12:34, Kent Watsen wrote:
> Hi Benoit,
> 
> Thanks for the report.   For this item, Confdc found one issue:
> 
>         ietf-zerotouch-bootstrap-server@2016-07-08.yang:256: error: unexpected keyword 'must'
> 
> Here is the line in question:
> 
>           anyxml configuration { // pyang validation doesn't support anydata yet
>             must "../configuration-handling";
>             description
>               "Any configuration data model known to the device.  It may
>                contain manufacturer-specific and/or standards-based data
>                models.";
>          }
> 
> From 6020bis, the ABNF is:
> 
>    anyxml-stmt         = anyxml-keyword sep identifier-arg-str optsep
>                          (";" /
>                           "{" stmtsep
>                               ;; these stmts can appear in any order
>                               [when-stmt]
>                               *if-feature-stmt
>                               *must-stmt
>                               [config-stmt]
>                               [mandatory-stmt]
>                               [status-stmt]
>                               [description-stmt]
>                               [reference-stmt]
>                            "}") stmtsep
> 
> 
> As far as I can tell, this should be valid YANG.
> 
> PS: I would rather be using anydata (not anyxml) but, as the comment above mentions, pyang validation (e.g., yang2dsdl) doesnt support YANG 1.1 statements yet, so Im temporarily using anyxml...
> 
> yang2dsdl -t data ietf-zerotouch-bootstrap-server\@2016-07-17.yang
> Unknown keyword anydata - this should not happen.
> 
> 
> Thanks,
> Kent
> 
> 
> From: Benoit Claise 
> Date: Saturday, July 16, 2016 at 8:25 PM
> To: "draft-ietf-netconf-zerotouch@ietf.org" , "netconf@ietf.org" 
> Subject: draft-ietf-netconf-zerotouch-09.txt: new error from confdc
> Resent-From: 
> Resent-To: Kent Watsen , <"mikael.abrahamsson@t-systems.se"@ietfa.amsl.com>
> Resent-Date: Saturday, July 16, 2016 at 8:25 PM
> 
> Dear authors,
> 
> Part of the IETF hackathon today, I integrated confdc , as a second YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. Reason? For example, confdc validates xpath while pyang doesn't.
> And confdc found an issue with your draft, which is now flagged as failing the YANG compilation.
> Please correct this issue.
> Note: you're not alone, look at the green dip today on green graph!
> 
> During the hackathon today, Carl Moberg also integrated the confdc output in his www.yangalidtor.com.
> This might help you.
> 
> Regards, Benoit
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Mon Jul 18 03:47:12 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF1C12D83C for ; Mon, 18 Jul 2016 03:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUfXXKEw9Fyx for ; Mon, 18 Jul 2016 03:47:07 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C4912D847 for ; Mon, 18 Jul 2016 03:47:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34581; q=dns/txt; s=iport; t=1468838826; x=1470048426; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=ka0kYsJfmFUXYNN4ABo8aDWr1t9PruDDyzEh/KFMn8o=; b=Yd45y3Sh/Omr+y+vUJK6HCJH8k+K2dZlM7SHsOpk6PB0OqvH2AQCN3uK G5XpR7+xIKbzC1muvApQCTKz10wQvYKHOhV7pbHYft+X58sZM+A2Txvdz cs9nrMxPuBTYqD680GCDWtYSVloaTyurzRIxb/vUfd3IHbTZukb8clF7h I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBACLsoxX/xbLJq1RCoQVKlKsXo4Uh?= =?us-ascii?q?hoCgX4BAQEBAQFmJ4RcAQEFGk0LFxwDAQIhDiEsAggGDQYCAQEVAod7Axe6Hw2?= =?us-ascii?q?EHgEBAQEBBQEBAQEBAQEBH4YqgXgIgk2CQ4FFCgYLAQY2DIUvAQSOC4VYhQ00h?= =?us-ascii?q?S+HFYIbgWuEWYMMI4VEhl+BRod5VIILHIFOOjKGCYE1AQEB?=
X-IronPort-AV: E=Sophos;i="5.28,383,1464652800";  d="scan'208,217";a="638619192"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 10:47:02 +0000
Received: from [10.61.227.61] ([10.61.227.61]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6IAl2qN014689 for ; Mon, 18 Jul 2016 10:47:02 GMT
References: <30133_1468838336_578CB1BF_30133_13979_1_6B7134B31289DC4FAF731D844122B36E01F10418@OPEXCLILM43.corporate.adroot.infra.ftgroup>
To: NETCONF 
From: Benoit Claise 
X-Forwarded-Message-Id: <30133_1468838336_578CB1BF_30133_13979_1_6B7134B31289DC4FAF731D844122B36E01F10418@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Message-ID: 
Date: Mon, 18 Jul 2016 12:47:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <30133_1468838336_578CB1BF_30133_13979_1_6B7134B31289DC4FAF731D844122B36E01F10418@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------4C70EAF3E51BEC21D3522019"
Archived-At: 
Subject: [Netconf] Fwd: ops-dir review of draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 10:47:10 -0000

This is a multi-part message in MIME format.
--------------4C70EAF3E51BEC21D3522019
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

FYI.
Thanks Lionel

Regards, B.


-------- Forwarded Message --------
Subject: 	ops-dir review of draft-ietf-netconf-restconf-15
Resent-Date: 	Mon, 18 Jul 2016 03:39:04 -0700
Resent-From: 	alias-bounces@ietf.org
Resent-To: 	andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, 
mjethanandani@gmail.com, mehmet.ersue@nokia.com, bclaise@cisco.com, 
joelja@bogus.com
Date: 	Mon, 18 Jul 2016 10:38:54 +0000
From: 	lionel.morand@orange.com
To: 	ops-dir@ietf.org 
CC: 	draft-ietf-netconf-restconf.all@ietf.org 
, ops-ads@tools.ietf.org 




I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document: draft-ietf-netconf-restconf-15
   
Summary:   This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG (v1 or v1.1), using the datastore concepts defined in NETCONF.
Status: Ready with issues/clarification
     
I'm (still) not (so) familiar with YANG and NETCONF and I've read the document as the newbie that I am. Therefore some of my comments may be irrelevant if out of context.

Summary:

The document is well written, the last version capturing most of the comments received so far.
The rational for this solution and the use of the protocol is clearly explained. And all the protocol aspects are clear enough for implementors.
Comments:
*Major comment: this solution defines an HTTP-based solution but with HTTP/1.1 in mind. It is said that HTTP/2 can be used but there is very few details on this possibility. More details are required if HTTP/2-based implementations are really foreseen .
*Major comment: the possible colocation of RESTCONF and NETCONF server could be improved. There are a lot of implied assumptions regarding the interactions between both servers that are not so trivial IMHO.
*Minor comment: Numerous cross-references between RESTCONF, NETCONF, YANG and HTTP may make the life difficult to the reader.

Detailed review provided below.

Regards,

Lionel

*************************
1.  Introduction

    This document defines an HTTP [RFC7230] based protocol called
    RESTCONF, for configuring data defined in YANG version 1 [RFC6020] or
    YANG version 1.1 [I-D.ietf-netmod-rfc6020bis], using the datastore
    concepts defined in NETCONF [RFC6241].

LM: What about HTTP/2 that "enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients."?

1.1.3.  YANG

    The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:

LM: It is missing, lately introduced in rfc6020bis:

    o  non-presence container

    o  presence container

1.3.  Data Model Driven API

    The RESTCONF protocol operates on a conceptual datastore defined with
    the YANG data modeling language.  The server lists each YANG module
    it supports using the "ietf-yang-library" YANG module, defined in
    [I-D.ietf-netconf-yang-library].  The server MUST implement the
    "ietf-yang-library" module, which MUST identify all the YANG modules
    used by the server.

LM: Could be clarified where it is listed: "and listing all implemented modules in the "/modules-state/module" list"

    The conceptual datastore contents, data-model-specific operations and
    event notifications are identified by this set of YANG modules.

LM: either this sentence is part of the previous paragraph or the sentence should be:

    "The conceptual datastore contents, data-model-specific operations and
     event notifications are identified by the set of YANG modules listed
     in the "/modules-state/module" list."

    The classification of data as configuration or non-configuration is
    derived from the YANG "config" statement.  Data ordering behavior is
    derived from the YANG "ordered-by" statement.

LM: "non-configuration data" is "state data" as per the definition of the "config" statement:
    
    "When a node is tagged with "config false",
    its subhierarchy is flagged as state data.  If it is tagged with
    "config true", its subhierarchy is flagged as configuration data."

1.4.  Coexistence with NETCONF

    RESTCONF can be implemented on a device that supports NETCONF.

LM: is it "RESTCONF server + NETCONF server" or any combination "client/server"?
LM: "colocated" is only relevant if there is protocol interaction between RESTCONF and NETCONF. And this interaction is described     in this section.
LM: when both servers are colocated, is it assummed that the RESTCONF server acts as a NETCONF client and "normal" NETCONF operations are performed between both?

    If the device supports :writable-running, all edits to configuration
    nodes in {+restconf}/data are performed in the running configuration
    datastore.  The URI template "{+restconf}" is defined in
    Section 1.1.6.

LM: Just for sake of clarity, "If the device supports" refers to the "if the NETCONF server colocated with the RESTCONF server supports", right? Applies to the rest of the section.

    Otherwise, if the device supports :candidate, all edits to
    configuration nodes in {+restconf}/data are performed in the
    candidate configuration datastore.  The candidate MUST be
    automatically committed to running immediately after each successful
    edit.

LM: "automatically" could be understood as "implicitly", that is not possible with NETCONF. If I'm correct, what is meant is that the edit operations in the candidate configuration datastore MUST be followed by a commit operation.

    Any edits from other sources that are in the candidate
    datastore will also be committed.  If a confirmed-commit procedure is
    in progress, then this commit will act as the confirming commit.

LM: s/If a confirmed-commit procedure is in progress/If a confirmed commit procedure is in progress,
LM: "in progress" means by another client?

    If
    the server is expecting a "persist-id" parameter to complete the
    confirmed commit procedure then the RESTCONF edit operation MUST fail
    with a "409 Conflict" status-line.

LM: s/If the server/If the NETCONF server
LM: this point is not clear for me. I understand from NETCONF that if a Persist-Id is not expected, the confirming commit must be issued on the same session that issued the confirmed commit. So even if the Persist-Id is not expected, the operaion will still fail. But I have certainly missed something.
LM: Would it be useful to give the associated error-tag to use in this case?

    If the device supports :startup, the device MUST automatically update
    the non-volatile "startup datastore", after the running datastore has
    been updated as a consequence of a RESTCONF edit operation.

LM: "automatically" here means "edit operation followed by a  operation from the  to the "?

    If a datastore that would be modified by a RESTCONF operation has an
    active lock from a NETCONF client, the RESTCONF edit operation MUST
    fail with a "409 Conflict" status-line.

LM: Would it be useful to give the associated error-tag to use in this case?

2.  Transport Protocol Requirements

2.1.  Integrity and Confidentiality

    HTTP/2 [RFC7540] MAY be used for RESTCONF.  The server MUST respond
    using a single HTTP/2 stream for all client requests from a stream.
    The server MAY respond using same HTTP/2 stream that was used for the
    corresponding request.

LM: the rest of the document focuses on HTTP/1.1. Is this section is enough to know how to support RESTCONF over HTTP/2?

3.  Resources

    [...]

    A resource can be considered a collection of data and the set of
    allowed methods on that data.

LM: s/A resource can be considered a collection of data/A resource can be considered as a collection of data

3.1.  Root Resource Discovery

    [...]
    
    If the XRD contains more than one link relation, then only the
    relation named "restconf" is relevant to this specification.

LM: please expand XRD (Extensible Reference Descriptor)

3.4.1.1.  Timestamp

    The last change time is maintained and the "Last-Modified"
    ([RFC7232], Section 2.2) header is returned in the response for a
    retrieval request.  The "If-Unmodified-Since" header can be used in
    edit operation requests to cause the server to reject the request if
    the resource has been modified since the specified timestamp.

LM: s/The "If-Unmodified-Since" header/The "If-Unmodified-Since" header ([RFC7232], Section 3.4)

3.5.1.  Timestamp

LM: the use of the timestamp regarding configuration and non-configuration data is quite confusing. it said in the same section:

    For configuration data resources, the server MAY maintain a last-
    modified timestamp for the resource, and return the "Last-Modified"
    header when it is retrieved with the GET or HEAD methods.
    [...]
    This timestamp is only affected by configuration data resources, and
    MUST NOT be updated for changes to non-configuration data.

    For non-configuration data resources, the server MAY maintain a last-
    modified timestamp for the resource, and return the "Last-Modified"
    header when it is retrieved with the GET or HEAD methods.  The
    timestamps for non-configuration data resources are updated in an
    implementation-specific manner.

LM: what is the difference between the "two" last-modified timestamps?

3.5.2.  Entity tag

LM: same comment as above regarding the use of ETag for configuration and non-configuration data.

3.5.3.  Encoding Data Resource Identifiers in the Request URI

    [...]

    A RESTCONF data resource identifier is not an XPath expression.

LM: what does it mean "is not"? Can be removed IMHO

3.5.3.1.  ABNF For Data Resource Identifiers

    [...]
    Note 1: The syntax for "api-identifier" and "key-value" MUST conform
    to the JSON identifier encoding rules in Section 4 of
    [I-D.ietf-netmod-yang-json].

LM: either it is a note and for information or it is a requirement. Cannot be both. I guess that the note could be moved as body text with normative language.

3.5.4.  Defaults Handling

LM: should it be "Default Handling" or "Default handlings"? The name of the URI is "defaults"


3.6.  Operation Resource

    [...]

    If the "rpc" or "action" statement has an "input" section then
    instances of these input parameters are encoded in the module
    namespace where the "rpc" or "action" statement is defined, in an XML
    element or JSON object named "input", which is in the module
    namespace where the "rpc" or "action" statement is defined.

    If the "rpc" or "action" statement has an "input" section and the
    "input" object tree contains any child data nodes which are
    considered mandatory nodes, then a message-body MUST be sent by the
    client in the request.

    [...]

LM: why not skip this text (and the following part) and describe the input/output + message-body cases in the sections 3.6.1 and 3.6.2. This will avoid some misalignements, especially regarding the mandatory presence of the message-body. For instance, here it is said in section 3.6:

    If the "rpc" or "action" statement has an "input" section and the
    "input" object tree contains any child data nodes which are
    considered mandatory nodes, then a message-body MUST be sent by the
    client in the request.

    If the "rpc" or "action" statement has an "input" section and the
    "input" object tree does not contain any child nodes which are
    considered mandatory nodes, then a message-body MAY be sent by the
    client in the request.

LM: whereas in section 3.6.1:

    If the "rpc" or "action" statement has an "input" section, then the
    "input" node is provided in the message-body, corresponding to the
    YANG data definition statements within the "input" section.

LM: in which it is assumed that a message-body is always there when "input" is present.
LM: Moreover, in section 3.6, it is not said what is the payload body carried in the message-body.

3.7.  Schema Resource

    [...]
    To retrieve a YANG module, a client first needs to get the URL for
    retrieving the schema, which is stored in the "schema" leaf.  Note
    that there is no required structure for this URL.  The URL value
    shown below is just an example.

LM: why do not recommend a default structure?

3.9.  Errors YANG Data Template

    [...]  It
    is not considered a resource type because no instances can be
    retrieved with a GET request.

LM: s/It is not considered a resource type/It is not considered as a resource type

4.  Operations

    The RESTCONF protocol uses HTTP methods to identify the CRUD
    operation requested for a particular resource.

LM: CRUD operation/CRUD operations

    The following table shows how the RESTCONF operations relate to
    NETCONF protocol operations and edit operations, which are identified
    with the NETCONF "nc:operation" attribute.

LM: as the table gives the mapping between RESCONF and NETCONF operations, it could be explain why OPTIONS and HEAD as no equivalence in NETCONF, even if obvious.

4.2.  HEAD

LM: it is not said if the server MUST implement this method (as for OPTIONS). Same comment for all the other methods.

4.3. GET

LM: when relevant, the error-tag used with error indicated in the status-line header would be useful to ensure a correct mapping of error cases with NETCONF error cases. Comment valids for other methods where error cases are described.

4.5.  PUT

    The PUT method is sent by the client to create or replace the target
    data resource.  A request message-body MUST be present, representing
    the new data resource, or the server MUST return "400 Bad Request"
    status-line.

LM: for creation of data resource, are POST and PUT operations? If not, what is the difference? If they are, is there any preference for creation of a data resource?

LM: No specific comments on the rest of the document. Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

.


--------------4C70EAF3E51BEC21D3522019
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  

    
  
  
    FYI.

    Thanks Lionel

    

    Regards, B.

    


      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            ops-dir review of draft-ietf-netconf-restconf-15
          

          

            Resent-Date:
            
            Mon, 18 Jul 2016 03:39:04 -0700
          

          

            Resent-From:
            
            alias-bounces@ietf.org
          

          

            Resent-To:
            
            andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net,
              mjethanandani@gmail.com, mehmet.ersue@nokia.com,
              bclaise@cisco.com, joelja@bogus.com
          

          

            Date: 
            Mon, 18 Jul 2016 10:38:54 +0000
          

          

            From: 
            lionel.morand@orange.com
          

          

            To: 
            ops-dir@ietf.org <ops-dir@ietf.org>
          

          

            CC: 
            draft-ietf-netconf-restconf.all@ietf.org
              <draft-ietf-netconf-restconf.all@ietf.org>,
              ops-ads@tools.ietf.org <ops-ads@tools.ietf.org>
          

        
      

      

      

      
I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document: draft-ietf-netconf-restconf-15
  
Summary:   This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG (v1 or v1.1), using the datastore concepts defined in NETCONF.
Status: Ready with issues/clarification
    
I'm (still) not (so) familiar with YANG and NETCONF and I've read the document as the newbie that I am. Therefore some of my comments may be irrelevant if out of context.

Summary:

The document is well written, the last version capturing most of the comments received so far.
The rational for this solution and the use of the protocol is clearly explained. And all the protocol aspects are clear enough for implementors.
Comments:
*Major comment: this solution defines an HTTP-based solution but with HTTP/1.1 in mind. It is said that HTTP/2 can be used but there is very few details on this possibility. More details are required if HTTP/2-based implementations are really foreseen .
*Major comment: the possible colocation of RESTCONF and NETCONF server could be improved. There are a lot of implied assumptions regarding the interactions between both servers that are not so trivial IMHO. 
*Minor comment: Numerous cross-references between RESTCONF, NETCONF, YANG and HTTP may make the life difficult to the reader.

Detailed review provided below.

Regards,

Lionel

*************************
1.  Introduction

   This document defines an HTTP [RFC7230] based protocol called
   RESTCONF, for configuring data defined in YANG version 1 [RFC6020] or
   YANG version 1.1 [I-D.ietf-netmod-rfc6020bis], using the datastore
   concepts defined in NETCONF [RFC6241].

LM: What about HTTP/2 that "enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients."?

1.1.3.  YANG

   The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:

LM: It is missing, lately introduced in rfc6020bis:

   o  non-presence container

   o  presence container

1.3.  Data Model Driven API

   The RESTCONF protocol operates on a conceptual datastore defined with
   the YANG data modeling language.  The server lists each YANG module
   it supports using the "ietf-yang-library" YANG module, defined in
   [I-D.ietf-netconf-yang-library].  The server MUST implement the
   "ietf-yang-library" module, which MUST identify all the YANG modules
   used by the server.

LM: Could be clarified where it is listed: "and listing all implemented modules in the "/modules-state/module" list"

   The conceptual datastore contents, data-model-specific operations and
   event notifications are identified by this set of YANG modules.

LM: either this sentence is part of the previous paragraph or the sentence should be:

   "The conceptual datastore contents, data-model-specific operations and
    event notifications are identified by the set of YANG modules listed 
    in the "/modules-state/module" list."

   The classification of data as configuration or non-configuration is
   derived from the YANG "config" statement.  Data ordering behavior is
   derived from the YANG "ordered-by" statement.   

LM: "non-configuration data" is "state data" as per the definition of the "config" statement:
   
   "When a node is tagged with "config false",
   its subhierarchy is flagged as state data.  If it is tagged with
   "config true", its subhierarchy is flagged as configuration data."

1.4.  Coexistence with NETCONF

   RESTCONF can be implemented on a device that supports NETCONF.

LM: is it "RESTCONF server + NETCONF server" or any combination "client/server"?
LM: "colocated" is only relevant if there is protocol interaction between RESTCONF and NETCONF. And this interaction is described     in this section.
LM: when both servers are colocated, is it assummed that the RESTCONF server acts as a NETCONF client and "normal" NETCONF operations are performed between both?

   If the device supports :writable-running, all edits to configuration
   nodes in {+restconf}/data are performed in the running configuration
   datastore.  The URI template "{+restconf}" is defined in
   Section 1.1.6.

LM: Just for sake of clarity, "If the device supports" refers to the "if the NETCONF server colocated with the RESTCONF server supports", right? Applies to the rest of the section.

   Otherwise, if the device supports :candidate, all edits to
   configuration nodes in {+restconf}/data are performed in the
   candidate configuration datastore.  The candidate MUST be
   automatically committed to running immediately after each successful
   edit.  

LM: "automatically" could be understood as "implicitly", that is not possible with NETCONF. If I'm correct, what is meant is that the edit operations in the candidate configuration datastore MUST be followed by a commit operation.  

   Any edits from other sources that are in the candidate
   datastore will also be committed.  If a confirmed-commit procedure is
   in progress, then this commit will act as the confirming commit.  

LM: s/If a confirmed-commit procedure is in progress/If a confirmed commit procedure is in progress,
LM: "in progress" means by another client?

   If
   the server is expecting a "persist-id" parameter to complete the
   confirmed commit procedure then the RESTCONF edit operation MUST fail
   with a "409 Conflict" status-line.

LM: s/If the server/If the NETCONF server
LM: this point is not clear for me. I understand from NETCONF that if a Persist-Id is not expected, the confirming commit must be issued on the same session that issued the confirmed commit. So even if the Persist-Id is not expected, the operaion will still fail. But I have certainly missed something.
LM: Would it be useful to give the associated error-tag to use in this case?

   If the device supports :startup, the device MUST automatically update
   the non-volatile "startup datastore", after the running datastore has
   been updated as a consequence of a RESTCONF edit operation.

LM: "automatically" here means "edit operation followed by a <copy-config> operation from the <running> to the <startup>"?

   If a datastore that would be modified by a RESTCONF operation has an
   active lock from a NETCONF client, the RESTCONF edit operation MUST
   fail with a "409 Conflict" status-line.

LM: Would it be useful to give the associated error-tag to use in this case?

2.  Transport Protocol Requirements

2.1.  Integrity and Confidentiality

   HTTP/2 [RFC7540] MAY be used for RESTCONF.  The server MUST respond
   using a single HTTP/2 stream for all client requests from a stream.
   The server MAY respond using same HTTP/2 stream that was used for the
   corresponding request.

LM: the rest of the document focuses on HTTP/1.1. Is this section is enough to know how to support RESTCONF over HTTP/2?

3.  Resources

   [...]

   A resource can be considered a collection of data and the set of
   allowed methods on that data.  

LM: s/A resource can be considered a collection of data/A resource can be considered as a collection of data

3.1.  Root Resource Discovery

   [...]
   
   If the XRD contains more than one link relation, then only the
   relation named "restconf" is relevant to this specification.

LM: please expand XRD (Extensible Reference Descriptor)

3.4.1.1.  Timestamp

   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section 2.2) header is returned in the response for a
   retrieval request.  The "If-Unmodified-Since" header can be used in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

LM: s/The "If-Unmodified-Since" header/The "If-Unmodified-Since" header ([RFC7232], Section 3.4) 

3.5.1.  Timestamp

LM: the use of the timestamp regarding configuration and non-configuration data is quite confusing. it said in the same section:

   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods.
   [...]
   This timestamp is only affected by configuration data resources, and
   MUST NOT be updated for changes to non-configuration data.

   For non-configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods.  The
   timestamps for non-configuration data resources are updated in an
   implementation-specific manner.

LM: what is the difference between the "two" last-modified timestamps?

3.5.2.  Entity tag

LM: same comment as above regarding the use of ETag for configuration and non-configuration data.

3.5.3.  Encoding Data Resource Identifiers in the Request URI

   [...]

   A RESTCONF data resource identifier is not an XPath expression.

LM: what does it mean "is not"? Can be removed IMHO

3.5.3.1.  ABNF For Data Resource Identifiers

   [...]
   Note 1: The syntax for "api-identifier" and "key-value" MUST conform
   to the JSON identifier encoding rules in Section 4 of
   [I-D.ietf-netmod-yang-json].

LM: either it is a note and for information or it is a requirement. Cannot be both. I guess that the note could be moved as body text with normative language.

3.5.4.  Defaults Handling

LM: should it be "Default Handling" or "Default handlings"? The name of the URI is "defaults"


3.6.  Operation Resource

   [...]

   If the "rpc" or "action" statement has an "input" section then
   instances of these input parameters are encoded in the module
   namespace where the "rpc" or "action" statement is defined, in an XML
   element or JSON object named "input", which is in the module
   namespace where the "rpc" or "action" statement is defined.

   If the "rpc" or "action" statement has an "input" section and the
   "input" object tree contains any child data nodes which are
   considered mandatory nodes, then a message-body MUST be sent by the
   client in the request.

   [...]

LM: why not skip this text (and the following part) and describe the input/output + message-body cases in the sections 3.6.1 and 3.6.2. This will avoid some misalignements, especially regarding the mandatory presence of the message-body. For instance, here it is said in section 3.6:

   If the "rpc" or "action" statement has an "input" section and the
   "input" object tree contains any child data nodes which are
   considered mandatory nodes, then a message-body MUST be sent by the
   client in the request.

   If the "rpc" or "action" statement has an "input" section and the
   "input" object tree does not contain any child nodes which are
   considered mandatory nodes, then a message-body MAY be sent by the
   client in the request.

LM: whereas in section 3.6.1:

   If the "rpc" or "action" statement has an "input" section, then the
   "input" node is provided in the message-body, corresponding to the
   YANG data definition statements within the "input" section.

LM: in which it is assumed that a message-body is always there when "input" is present.
LM: Moreover, in section 3.6, it is not said what is the payload body carried in the message-body.

3.7.  Schema Resource

   [...]
   To retrieve a YANG module, a client first needs to get the URL for
   retrieving the schema, which is stored in the "schema" leaf.  Note
   that there is no required structure for this URL.  The URL value
   shown below is just an example.

LM: why do not recommend a default structure?

3.9.  Errors YANG Data Template

   [...]  It
   is not considered a resource type because no instances can be
   retrieved with a GET request.

LM: s/It is not considered a resource type/It is not considered as a resource type

4.  Operations

   The RESTCONF protocol uses HTTP methods to identify the CRUD
   operation requested for a particular resource.

LM: CRUD operation/CRUD operations

   The following table shows how the RESTCONF operations relate to
   NETCONF protocol operations and edit operations, which are identified
   with the NETCONF "nc:operation" attribute.

LM: as the table gives the mapping between RESCONF and NETCONF operations, it could be explain why OPTIONS and HEAD as no equivalence in NETCONF, even if obvious.

4.2.  HEAD

LM: it is not said if the server MUST implement this method (as for OPTIONS). Same comment for all the other methods.

4.3. GET

LM: when relevant, the error-tag used with error indicated in the status-line header would be useful to ensure a correct mapping of error cases with NETCONF error cases. Comment valids for other methods where error cases are described.

4.5.  PUT

   The PUT method is sent by the client to create or replace the target
   data resource.  A request message-body MUST be present, representing
   the new data resource, or the server MUST return "400 Bad Request"
   status-line.

LM: for creation of data resource, are POST and PUT operations? If not, what is the difference? If they are, is there any preference for creation of a data resource?

LM: No specific comments on the rest of the document. Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

.



    

  


--------------4C70EAF3E51BEC21D3522019--


From nobody Mon Jul 18 05:59:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A071412D9F0 for ; Mon, 18 Jul 2016 05:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh-WUWEu-NhO for ; Mon, 18 Jul 2016 05:59:30 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB84D12D9FD for ; Mon, 18 Jul 2016 05:59:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=107; q=dns/txt; s=iport; t=1468846770; x=1470056370; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=cmHWnNtue/fPe8LYlkwInKq1V89wm7ysVLkufd3lAS4=; b=a2a/1zKjYiRWUynP1X/uk4DJTwp99tROVw/0jggL+uXEdbIChCB7PZQp KcFAe36jFn9CiAR3OuPPrB4YlksKIUK/UMU3yRi0utqFFw+Q24FbC12Lc RssnHd6+Q6Uim08vVC75REr3dkspP6AqtBUKp1sPb/nkIb1mGZjSURXFG s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOCABy0YxX/xbLJq1bhBUqtHGGVSKHa?= =?us-ascii?q?REBAQEBAQEBZSeFBhV2AiYCXw0IAQGILA6gXY9ijW4BAQgCAR8FgQGFKYF4CIo?= =?us-ascii?q?OgloBBJkkhhOITIFVAYd6hWeQHjQgg3U6h3ABAQE?=
X-IronPort-AV: E=Sophos;i="5.28,384,1464652800"; d="scan'208";a="635780441"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 12:59:28 +0000
Received: from [10.61.227.61] ([10.61.227.61]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6ICxRuh017303 for ; Mon, 18 Jul 2016 12:59:28 GMT
To: NETCONF 
From: Benoit Claise 
Message-ID: <92e3e62a-2a55-afb2-1279-1b02361ec0b4@cisco.com>
Date: Mon, 18 Jul 2016 14:59:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] gRPC
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 12:59:31 -0000

Dear all,

See gRPC in RTGWG.
https://datatracker.ietf.org/meeting/96/agenda/rtgwg/

Regards, Benoit


From nobody Mon Jul 18 08:09:00 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1153E12DC91; Mon, 18 Jul 2016 08:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.439
X-Spam-Level: ****
X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=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 XLrfhnnCPW84; Mon, 18 Jul 2016 08:08:49 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED8512DE47; Mon, 18 Jul 2016 07:42:42 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.163.227; 
From: "Susan Hares" 
To: 
Date: Mon, 18 Jul 2016 10:41:51 -0400
Message-ID: <027001d1e102$8f4bf8c0$ade3ea40$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0271_01D1E0E1.083ACDF0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AdHhAfhAC8pOrU0iQXiKJFqNZc18Ig==
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Cc: 'Netconf' , netmod@ietf.org
Subject: [Netconf] Second meeting time for I2RS this week
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jul 2016 15:08:51 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0271_01D1E0E1.083ACDF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Due to a wonderful discussion on the I2RS ephemeral state, we did not
complete the discussion of the data model.  The Chairs have asked the AD and
IETF secretariat for a second meeting this week.  Please stay tune to the
mail list for an announcement of the work. 

 

Sue 


------=_NextPart_000_0271_01D1E0E1.083ACDF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Due to a =
wonderful discussion on the I2RS ephemeral state, we did not complete =
the discussion of the data model.  The Chairs have asked the AD and =
IETF secretariat for a second meeting this week.  Please stay tune =
to the mail list for an announcement of the work. 
 
Sue =


------=_NextPart_000_0271_01D1E0E1.083ACDF0--


From nobody Tue Jul 19 04:02:15 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ADB12D179 for ; Tue, 19 Jul 2016 04:02:14 -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 autolearn_force=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 M3NaCpS2zjYu for ; Tue, 19 Jul 2016 04:02:11 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D110412D12E for ; Tue, 19 Jul 2016 04:02:10 -0700 (PDT)
Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 86DC050AC8; Tue, 19 Jul 2016 07:02:09 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Leonard 
In-Reply-To: 
Date: Tue, 19 Jul 2016 04:02:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf , media-types@iana.org
Subject: Re: [Netconf] review request for media type application/yang-patch+json
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 11:02:14 -0000

application/yang-patch+json and application/yang-data+json look fine to =
me. Carry on.

Sean

> On Jul 8, 2016, at 4:10 PM, Andy Bierman  wrote:
>=20
> Hi,
>=20
> Here is the revised application/yang-patch+json media type =
registration request
>=20
>=20
>            Type name: application
>       Subtype name: yang-patch+json
>=20
>       Required parameters: None
>=20
>       Optional parameters: None
>=20
>      // RFC Ed.: replace draft-ietf-netmod-yang-json with
>      // the actual RFC reference for JSON Encoding of YANG Data,
>      //  and remove this note.
>=20
>      // RFC Ed.: replace draft-ietf-netmod-yang-metadata with
>      // the actual RFC reference for JSON Encoding of YANG Data,
>      //  and remove this note.
>=20
>      // RFC Ed.: replace 'XXXX' with the real RFC number,
>      // and remove this note
>=20
>       Encoding considerations: 8-bit
>          Each conceptual YANG data node is encoded according to
>          [draft-ietf-netmod-yang-json]. A data annotation is
>          encoded according to [draft-ietf-netmod-yang-metadata]
>          In addition, the "yang-patch" YANG data template found
>          in [RFCXXXX] defines the structure of a YANG Patch request.
>=20
>      // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
>      // section number for Security Considerations
>      // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
>      // RFC number, and remove this note.
>=20
>       Security considerations: Security considerations related
>          to the generation and consumption of RESTCONF messages
>          are discussed in Section NN of [RFCXXXX].
>          Additional security considerations are specific to the
>          semantics of particular YANG data models. Each YANG module
>          is expected to specify security considerations for the
>          YANG data defined in that module.
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Interoperability considerations: [RFCXXXX] specifies the format
>          of conforming messages and the interpretation thereof.
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Published specification: RFC XXXX
>=20
>       Applications that use this media type: Instance document
>         data parsers used within a protocol or automation tool
>         that utilize the YANG Patch data structure.
>=20
>       Fragment identifier considerations: The syntax and semantics
>          of fragment identifiers are the same as specified for the
>         "application/json" media type.
>=20
>       Additional information:
>=20
>         Deprecated alias names for this type: N/A
>         Magic number(s): N/A
>         File extension(s): .json
>         Macintosh file type code(s): "TEXT"
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Person & email address to contact for further information: See
>          Authors' Addresses section of [RFCXXXX].
>=20
>       Intended usage: COMMON
>=20
>       Restrictions on usage: N/A
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Author: See Authors' Addresses section of [RFCXXXX].
>=20
>       Change controller: Internet Engineering Task Force
>          (mailto:
> iesg&ietf.org
> ).
>=20
>       Provisional registration? (standards tree only): no
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Tue Jul 19 04:10:08 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC8C12D1B8 for ; Tue, 19 Jul 2016 04:10:06 -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 autolearn_force=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 UJy_aqagY7FE for ; Tue, 19 Jul 2016 04:10:04 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7133612D0BF for ; Tue, 19 Jul 2016 04:10:04 -0700 (PDT)
Received: from [192.168.123.151] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1FD7F509B5; Tue, 19 Jul 2016 07:10:02 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Leonard 
In-Reply-To: 
Date: Tue, 19 Jul 2016 04:10:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf , media-types@iana.org
Subject: Re: [Netconf] review request for media type application/yang-patch
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 11:10:06 -0000

My feedback remains that these ought to remain =
application/yang-patch+xml and application/yang-data+xml.

I would be happy to be rebuked (with appropriate justifications), but =
have not heard compelling reasons to vary from that course.

Three observations:
1. If you occupy application/yang-patch as the XML variant now, what =
happens when you have CBOR or some other fancy format du jour? Now =
you=E2=80=99ve used up the =E2=80=9Cmain one=E2=80=9D.

2. Consider that image/svg+xml uses +xml, but doesn=E2=80=99t use =
XPointer for fragment identifiers. It uses =E2=80=9CSVG barenames=E2=80=9D=
 or =E2=80=9CSVG views=E2=80=9D. See =
.

3. If the fragment identifier syntax is what=E2=80=99s causing the =
stumbling block, how about application/yang-patch-xml and =
application/yang-data-xml ? That keeps the format front-and-center but =
avoids the (perceived) fragment identifier stumbling block.

Best regards,

Sean


> On Jul 8, 2016, at 4:10 PM, Andy Bierman  wrote:
>=20
> Hi,
>=20
> Here is the revised application/yang-patch media type registration =
request
> (was application/yang-patch+xml)
>       Type name: application
>=20
>       Subtype name: yang-patch
>=20
>       Required parameters: None
>=20
>       Optional parameters: None
>=20
>      // RFC Ed.: replace draft-ietf-netmod-rfc6020bis with
>      // the actual RFC reference for YANG 1.1, and remove this note.
>=20
>      // RFC Ed.: replace 'XXXX' with the real RFC number,
>      // and remove this note
>=20
>       Encoding considerations: 8-bit
>          Each conceptual YANG data node is encoded according to the
>          XML Encoding Rules and Canonical Format for the specific
>          YANG data node type defined in =
[draft-ietf-netmod-rfc6020bis].
>          In addition, the "yang-patch" YANG data template found
>          in [RFCXXXX] defines the structure of a YANG Patch request.
>=20
>      // RFC Ed.: replace 'NN' in Section NN of [RFCXXXX] with the
>      // section number for Security Considerations
>      // Replace 'XXXX' in Section NN of [RFCXXXX] with the actual
>      // RFC number, and remove this note.
>=20
>       Security considerations: Security considerations related
>          to the generation and consumption of RESTCONF messages
>          are discussed in Section NN of [RFCXXXX].
>          Additional security considerations are specific to the
>          semantics of particular YANG data models. Each YANG module
>          is expected to specify security considerations for the
>          YANG data defined in that module.
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>=20
>      // note
>=20
>       Interoperability considerations: [RFCXXXX] specifies the format
>          of conforming messages and the interpretation thereof.
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Published specification: RFC XXXX
>=20
>       Applications that use this media type: Instance document
>         data parsers used within a protocol or automation tool
>         that utilize the YANG Patch data structure.
>=20
>       Fragment identifier considerations: The fragment field in the
>          request URI has no defined purpose.
>=20
>       Additional information:
>=20
>         Deprecated alias names for this type: N/A
>         Magic number(s): N/A
>         File extension(s): .xml
>         Macintosh file type code(s): "TEXT"
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Person & email address to contact for further information: See
>          Authors' Addresses section of [RFCXXXX].
>=20
>       Intended usage: COMMON
>=20
>       Restrictions on usage: N/A
>=20
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
>=20
>       Author: See Authors' Addresses section of [RFCXXXX].
>=20
>       Change controller: Internet Engineering Task Force
>          (mailto:
> iesg&ietf.org
> ).
>=20
>       Provisional registration? (standards tree only): no
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Tue Jul 19 06:02:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8272312D7BC for ; Tue, 19 Jul 2016 06:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iWrJP9v4wkm5 for ; Tue, 19 Jul 2016 06:02:28 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F0D12D7FC for ; Tue, 19 Jul 2016 05:59:18 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-de-578e24239fa4
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 87.49.18043.3242E875; Tue, 19 Jul 2016 14:59:16 +0200 (CEST)
Received: from [100.94.38.215] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.294.0; Tue, 19 Jul 2016 14:59:15 +0200
To: Andy Bierman , Jan Lindblad 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57851AC9.1090208@seguesoft.com> <43D8151A-D4D9-4C25-A739-2B1EB46F74CE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> 
From: Balazs Lengyel 
Message-ID: <15eb30f4-94b2-21c1-c3d6-21291f18cc52@ericsson.com>
Date: Tue, 19 Jul 2016 14:59:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2K7rq6KSl+4wYT1XBYPjsxit/g/q4/R Yuqm26wOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujFuHdzEX3D3LWHGi5SJ7 A+P0uC5GTg4JAROJCZe2sELYYhIX7q1n62Lk4hASOMIo0dzXzA7hrGaUWLX/AViVsICFxJe/ /8FsEQFXiavvm5lBbCGBLewSh2aIgtjMAnISi3/0MIHYbAJGElP7z7OA2LwC9hINV56xg9gs AqoS/X9egMVFBWIkGm8fZoeoEZQ4OfMJWJxTIFDi9sE9bBAz9SWu37nPCmHLSzRvnQ21V0Pi 4YW/rBMYBWchaZ+FpGUWkpYFjMyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQLD+OCW31Y7 GA8+dzzEKMDBqMTDqyDZGy7EmlhWXJl7iFGCg1lJhNdauS9ciDclsbIqtSg/vqg0J7X4EKM0 B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA2Ovv6/2568VPz3nvXc/5Dq9K1vmp8GhSuXj F09KPQip/rFisn3f5IUr1O/Fn5B42/H4YeYRhSl7OmsuLE+zijm44mHkjm8KzBzLpj/sers1 VW7plsadypWmCfZNx58Y5/TUWs5a1vfu+eQF/UEajD5CUp4drbOmbBX/ZJ/aNkF8xebz+Z6b pn5RYinOSDTUYi4qTgQANhwjRl8CAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 13:02:32 -0000


  
    
  
  
    
+ 1 or more like +++1000  I always fought against them.

    

    
The added value NP containers have compared to P containers is
      very low. 

      The added complication is very high. A whole new concept of
      existing/disappearing data node is introduced, with many special
      rules, some of which are still not clear.

    
Balazs

    

    

    
On 2016-07-15 09:24, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I do not like NP containers at all.

        
They have so many special rules.

        
I don't know what problem is being solved by having them at
          all.

        
Also RFC 6241 defines NETCONF, not YANG.

        


        

        
Even in the YANG 1.1 spec, it says MAY delete but does not
          say MAY create anywhere.

        
YANG does not say NP containers cannot be created or
          deleted

        

        
by the client.

        


        

        


        

        
Andy

        


        

      

      


        
On Thu, Jul 14, 2016 at 11:46 PM, Jan
          Lindblad <janl@tail-f.com>
          wrote:

          

            
In order to reach rough
              consensus on the interpretation of the
              default-operation=none sequence, I think we need to start
              with coming to a common understanding of what NP
              containers are. Can NP containers be "created" and
              "deleted" just like P containers?
              


              

              
Here's a test to see if there is any difference
                between the behavior of p and np containers:

              


              

              
list t {

              
    key a;

              
    leaf a { type uint32; }

              
    container np {

              
        must "../a > 10";

              
    }

              
    container p {

              
        presence "...";

              
        must "../a > 20";

              
    }

              
}

              


              

              
The config is initially empty. Now, would it be
                possible to

              


              

              
a) create an instance with a = 5 if there is no
                mention of np and p in the edit-config?

              
b) create an instance with a = 5 if np (but not p) is
                "created" in the edit-config?

              
c) create an instance with a = 15 if there is no
                mention of np and p in the edit-config?

              
d) create an instance with a = 15 if p is created in
                the edit-config?

              

                


                

              

              
My own answer is that only operation c is allowed.
                "creation" of an NP container is irrelevant, while
                creation of a P container makes a difference. An NP
                container is simply a structural element, and does not
                need to be "created" to exist, but empty NP containers
                MAY not be reported since they are meaningless anyway.

              


              

              
If must statements in np containers are in effect
                even if the client isn't explicitly "creating" or
                mentioning the container, then I find it hard to
                understand the viewpoint that "creation" of NP
                containers makes any difference.

              


              

              
/jan

              


              

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
I
                                                  guess I don’t really
                                                  see NP-containers as
                                                  “config”.  They are
                                                  just structure and
                                                  filtered out when
                                                  empty.  I don’t really
                                                  see this as the server
                                                  “deleting” those
                                                  containers.  It just
                                                  suppresses them in
                                                  <get-config>
                                                  output.   

                                            

                                          

                                        

                                        
Please show me the RFC text
                                          that says the server can
                                          filter out NP containers.

                                        
All config=true data nodes
                                          are config.

                                      

                                    

                                  

                                

                                


                                

                                
In a very technical sense, I
                                  suppose the above statement is
                                  correct. An NP container is of course
                                  config true if it sits in the config
                                  true part of the tree. At the same
                                  time I agree with Janson's view that
                                  NP containers are just structure, so
                                  the question of their "existence" is
                                  moot. 

                                


                                

                                
Here's what RFC 6020, sec 7.5 says
                                  on the topic:

                                


                                

                                

                                  
   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.


                                  


                                  

                                

                                
So NP containers "exist only for
                                  organizing the hierarchy" while a P
                                  container "has an explicit meaning". I
                                  guess this implies NP containers
                                  having no meaning. Further down in
                                  7.5.1, re P containers, it is noted
                                  that:

                                


                                

                                

                                  
   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.


                                  

                                    
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.


                                  

                                  


                                  

                                

                                
Based on these fragments, I
                                  conclude that NP containers have zero
                                  bits of information. This means the
                                  existence/absence of an NP container
                                  cannot be known/stored/remembered even
                                  internally by a conforming system. The
                                  existence/absence of an NP container
                                  is a moot question. It's a bit like
                                  asking for the value of a void
                                  function. It's there, it has a name,
                                  but no value.

                                


                                

                                
Implementations that receive a
                                  <get> or <get-config>
                                  request that contains an NP container
                                  will have to decide whether to include
                                  the NP container in the response or
                                  not. Since the existence of the NP
                                  container cannot be read from a
                                  database/etc (it has zero bits of
                                  information), the implementation will
                                  have to use some other way to
                                  determine whether to include it or
                                  not.

                                


                                

                                
In order to make the life easier
                                  for implementors, the following MAY
                                  was introduced in sec 7.5.7:

                                


                                

                                

                                  
   A NETCONF server that replies to a <get> or <get-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.

                                  


                                  

                                

                                
So the NP container has to be
                                  included if it has children, or else
                                  the structural function of the
                                  container would be lost. If the NP
                                  container is empty, it may or may not
                                  be sent. Since an NP container has
                                  zero bits of information, this
                                  decision would not be based on whether
                                  it has been previously "created" or
                                  "deleted", but on implementation
                                  considerations. One possible approach
                                  is to always include it, another to
                                  actually check if there are any
                                  children, and only return it then.

                                


                                

                                
Either way, NP containers alone
                                  have no meaning/information, they are
                                  only there for structure.

                                

                                

                                  

                                    

                                      

                                        
A false must-stmt in an
                                          NP-container is still an
                                          error.

                                      

                                    

                                  

                                

                                


                                

                                
Certainly. Must statements on an NP
                                  container are always evaluated, even
                                  if the container hasn't been "created"
                                  or mentioned by a client, and even if
                                  it has no child elements.

                                

                                

                                  

                                    

                                      

                                        
As Lada has pointed out
                                          many times, the text about

                                        
NP containers not being
                                          part of the data model is just
                                          wrong.

                                      

                                    

                                  

                                

                                


                                

                                
I think the length of this
                                  discussion implies we should include
                                  this topic in the upcoming YANG FAQ.

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
The
                                                  server should not
                                                  error in the cases
                                                  Mahesh & Einar
                                                  show -> the
                                                  presence/existence of
                                                  NP-containers
                                                  shouldn’t really
                                                  affect behavior (since
                                                  they aren’t really
                                                  config). 

                                            

                                          

                                        

                                      

                                    

                                  

                                

                                I agree with the above.

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
But
                                                  I’m not positive what
                                                  you mean by “manager
                                                  needs to guard”.  Do
                                                  you agree that the
                                                  server should not
                                                  error in those cases
                                                  below ?

                                            

                                          

                                        

                                        
The YANG text says a server
                                          MAY delete an empty NP
                                          container.

                                        
Using
                                          default-operation=none implies
                                          that the client is sure the
                                          nodes for operation=none

                                        
actually exist.  Because of
                                          this YANG detail, the client
                                          cannot be sure so using

                                        
default-operation=none may
                                          not work.

                                      

                                    

                                  

                                

                                


                                

                                
I disagree with this conclusion.
                                  Even using default-operation=none the
                                  transactions must be guaranteed to
                                  work by a conforming implementation.
                                  NP containers cannot be
                                  created/deleted in a deeper sense of
                                  the word since they have zero
                                  information content. They can only be
                                  referred to. Any must statements
                                  within the container must be evaluated
                                  regardless of the client ever
                                  mentioning the container.

                                
                                    


                                    

                                  

                            

                          

                          


                          

                          


                          

                          
I do not agree that
                            default-operation=none does not apply to NP
                            containers.

                          


                          

                          
This is why it was such a bad decision to
                            spread little pieces of NETCONF

                          
all over the YANG RFC. RFC 6241 defines
                            the 'default-operation' leaf

                          
and it does not say anything about
                            special treatment for NP containers.

                          


                          

                          

                            
   none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.


                          

                          


                          

                          
 

                          

                            

                              

                                    
/jan

                                    


                                    

                                  

                            

                          

                        

                        

                      

                      
Andy

                    

                  

                

                

              

            

          

        

        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Jul 19 06:41:01 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2912D9B2 for ; Tue, 19 Jul 2016 06:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dMX-bYsRrn4P for ; Tue, 19 Jul 2016 06:40:55 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21F012DF00 for ; Tue, 19 Jul 2016 06:12:39 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-dc-578e27458080
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.3C.18043.5472E875; Tue, 19 Jul 2016 15:12:37 +0200 (CEST)
Received: from [100.94.38.215] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.294.0; Tue, 19 Jul 2016 15:12:37 +0200
To: Jan Lindblad , Xiang Li 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>
From: Balazs Lengyel 
Message-ID: <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com>
Date: Tue, 19 Jul 2016 15:12:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2J7oK6rel+4QeNqG4v/s/oYLaZuus1q 8W3TH2YHZo8lS34yeTxc0sHisfHXYpYA5igum5TUnMyy1CJ9uwSujM87rjAWdIVVzPz9m7GB 8bpNFyMnh4SAicSqy12MELaYxIV769m6GLk4hASOMEoceXCWCcJZzSjx49F8VpAqYQELiS9/ /4PZIgIuEgte/GGFKHrCLrH7/0wmkASzgJzE4h89YDabgJHE1P7zLCA2r4C9xNKGVewgNouA qsTceXfBVosKxEg03j7MDlEjKHFy5hOwek4BO4lNTdtZIGbqS1y/c58VwpaXaN46mxnEFhLQ kHh44S/rBEbBWUjaZyFpmYWkZQEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwDA+uOW3 1Q7Gg88dDzEKcDAq8fAqSPaGC7EmlhVX5h5ilOBgVhLhvafaFy7Em5JYWZValB9fVJqTWnyI UZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qB0TlBd1Z9DReT1Ea3q3+5e5Wehr296VLg 6sDRNzVswYpXRzUM/hn8nO70rq5phkGgYIS4hMCag2+Ni69912LpeLbtosl+viUnXXO/qOiw Xd6V0Sd7yPqpUW+d+blN5SaXTRrq17vqnVD493DGk5Lg6C+qS6duX5zrd6B1YubHo1rRbZbn GBvdlFiKMxINtZiLihMBYIXt518CAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 13:40:59 -0000


  
    
  
  
    
Hello Jan,

    
As I don't see a way to kill NP containers (my first wish) I
      agree they should be clarified.  Currently the RFC says: 

    

    
"If a container does not have a "presence" statement and the last

         child node is deleted, the NETCONF server MAY delete the
      container." 

    

    
This allows deleting only when the last child node is deleted. It
      does not allow deleting an NP container after an explicit create.

    

    
Your table does not directly answer some key questions for me:

    
Q1) Is it allowed to create it explicitly? Yes/No?

      Q2) Is it allowed to create it, then create it again? For a P
      container this would result in a create-failed. For NP, allowed or
      no?

      Q3) If it is allowed to create them, will they exist and continue
      to exist in the database, or can the server delete them any time?

      Q4) Does the NP container modify the behavior of edit-config none?
      Should we fail or succeed in the provided examples? Yes/No?

      Q5) When are must statements that are direct substatements of an
      NP container validated? Following your logic IMHO such must
      statements MUST NOT be allowed in YANG at all.  If an NP container
      has no meaning why do we connect checks to them?

    
I propose to write an errata about this immediately after the
      YANG 1.1 RFC comes out.

    

    
regards Balazs

    

    

    
On 2016-07-16 09:31, Jan Lindblad
      wrote:

    

    

      
      

        

          

            

              

                
(f) should be accepted without an error
                    IMO.  

                  

              

            

            

            Ok. If f) is accepted then it
              indicates the server chooses to delete an empty container

            or it basically ignore the operation
              to create only a NP container node.

          

        

        


        

        
I agree with this.

        


        

        
I also agree that RFC 6020 could spell this out in a more
          direct way. Currently the description of NP and P containers
          does not contain a table with the properties of each, but
          instead enumerates how P containers differ from NP containers
          in plain english. In order to build a such a table, I've
          collected quotes on each type here:

        


        

        
P-container qoutes:

        
- "presence in the configuration has an explicit meaning"

        
- "presence of the container itself is configuration data"

        
- "representing a single bit of configuration data"

        
- "These containers are explicitly created and deleted"

        
- "The "presence" statement assigns a meaning to the
          presence of a container in the data tree"

        


        

        
NP-container qoutes:

        
- "exist only for organizing the hierarchy of data nodes"

        

          
- "container has no meaning of its own, existing
            only to contain child nodes"

        

        
- "the container is used to give some structure to the
          data, and it carries no meaning by itself"

        
- "MAY choose not to send a container element if the
          container node does not have the "presence" statement and no
          child nodes exist"

        
- "a client ... must be prepared to handle the case that a
          container node without a "presence" statement is not present"

        


        

        
Based on the above quotes, I believe this to be a fair
          description of the P and NP container differences in a tabular
          form:

        


        

        
                             
                | P-container | NP-container |

        
----------------------------------+-------------+--------------+

        
Organizing the hierarchy    
                 |      Y      |       Y      |

        
May have child nodes        
                 |      Y      |       Y      |

        
Existence has meaning        
                |      Y      |       N      |

        
Is
            configuration data             |      Y      |       N    
             |

        
Information content          
                |    1 bit    |    0 bits    |

        
Explicitly created and
            deleted    |      Y      |       N      |

        
Suppress when empty          
                |      N      |      MAY     |

        

          
----------------------------------+-------------+--------------+

          


            

        

        
With this background, I consider it clear that "creation"
          and "deletion" of P-containers has no effect on the
          configuration. In fact, a conforming implementation cannot
          even remember/know if a P-container has been created or not
          since it has zero bits of information. P-containers aren't
          really configuration data, even if they may be located in the
          config true part of the world.

        


        

        
If anyone sees anything wrong, unfounded or unclear with
          the table above, I think it would be of high general interest
          that this is pointed out asap.

        


        

        
/jan

        


        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Jul 19 07:27:15 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE82E12D958 for ; Tue, 19 Jul 2016 07:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 5U7_Ed_imGV7 for ; Tue, 19 Jul 2016 07:27:07 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A011212D9E2 for ; Tue, 19 Jul 2016 06:48:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6894E74D; Tue, 19 Jul 2016 15:48:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g8-xR-uWwJti; Tue, 19 Jul 2016 15:48:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 Jul 2016 15:48:36 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46BCC20069; Tue, 19 Jul 2016 15:48:36 +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 29h9sLPh_58I; Tue, 19 Jul 2016 15:48:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42FC220078; Tue, 19 Jul 2016 15:48:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 367243BDA399; Tue, 19 Jul 2016 15:48:35 +0200 (CEST)
Date: Tue, 19 Jul 2016 15:48:35 +0200
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Message-ID: <20160719134835.GB50107@elstar.local>
Mail-Followup-To: Balazs Lengyel , Jan Lindblad , Xiang Li , Netconf 
References:   <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 14:27:10 -0000

On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:
>    Hello Jan,
> 
>    As I don't see a way to kill NP containers (my first wish) I agree they
>    should be clarified.  Currently the RFC says:
> 
>    "If a container does not have a "presence" statement and the last
>       child node is deleted, the NETCONF server MAY delete the container."
>

Having to track whether a container was created to be empty or whether
it just became empty seems like additional complexity for no real
value. I think the text should likely have said:

   "If a container does not have a "presence" statement and the container
    has no child nodes, the NETCONF server MAY delete the container."

The whole problem can be easily prevented by having clients sending
edit-configs that do not rely on a server maintaining empty containers.

/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 Jul 19 15:36:59 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A6712D0A6 for ; Tue, 19 Jul 2016 15:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTItxcZWd6GI for ; Tue, 19 Jul 2016 15:36:56 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBC812B025 for ; Tue, 19 Jul 2016 15:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1230; q=dns/txt; s=iport; t=1468967816; x=1470177416; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=h4nEow1YJm0sqeHnsKrhPY5fFndnNYpYO9VcOvEXF6I=; b=aJR6Oe45bX/1KCWVoFx7SlFpe8vrS8r184f7DJPkIc6EfhKwHc4Hk5Nb ilTUIGCmfQMB4ER7cgWnQjhOtLcYc4AVVFUgMHTb33jjJOxPOaH6gTzpe 1E4WUQm/gLjYI3/D1STJKLHtPBnqpaK67r/2kVSgYiq0s8S1Qegquh/hX A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbDQB5qo5X/xbLJq1dhD+7OoYaAoF/A?= =?us-ascii?q?QEBAQEBZieEXQEFOFELGC5XBgEMCAEBiCy9FAEBAQEBAQEBAgEBAQEBASGGKoF?= =?us-ascii?q?4glWEKoVxAQSZJI5iiVCFZ5AeVIILHIFOOohXAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,391,1464652800"; d="scan'208";a="636836562"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 22:36:54 +0000
Received: from [10.61.202.157] ([10.61.202.157]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6JMarWP006993; Tue, 19 Jul 2016 22:36:54 GMT
To: Balazs Lengyel , Jan Lindblad , Xiang Li , Netconf 
References:   <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local>
From: Robert Wilton 
Message-ID: <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>
Date: Wed, 20 Jul 2016 00:36:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160719134835.GB50107@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 22:36:58 -0000

On 19/07/2016 15:48, Juergen Schoenwaelder wrote:
> On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:
>>     Hello Jan,
>>
>>     As I don't see a way to kill NP containers (my first wish) I agree they
>>     should be clarified.  Currently the RFC says:
>>
>>     "If a container does not have a "presence" statement and the last
>>        child node is deleted, the NETCONF server MAY delete the container."
>>
> Having to track whether a container was created to be empty or whether
> it just became empty seems like additional complexity for no real
> value. I think the text should likely have said:
>
>     "If a container does not have a "presence" statement and the container
>      has no child nodes, the NETCONF server MAY delete the container."
>
> The whole problem can be easily prevented by having clients sending
> edit-configs that do not rely on a server maintaining empty containers.
+1.

But I also agree with Balazs that YANG "must" statements on a np 
container are a bit horrible - intuitively I think that I would prefer 
that they are only bound to schema nodes that can actually contain 
information.  But that ship has already sailed ...

Rob

>
> /js
>


From nobody Tue Jul 19 16:55:29 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BAD12D98E for ; Tue, 19 Jul 2016 16:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyvNCxVp4TQW for ; Tue, 19 Jul 2016 16:55:25 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC5F12D955 for ; Tue, 19 Jul 2016 16:55:25 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id n129so1710455vke.3 for ; Tue, 19 Jul 2016 16:55:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZdV+rjclpUxE5VXDpqJsyBoeJOByvOH6+dS7uJqKgh4=; b=hdBwNWYFRcBsC7HyRXTs5agrjzeOHbvDXoj5NoS9JUWjZypINhbRZMm/YuqNT+Qg/d cQCUtXx2Gj/F3CrlndF1otvaekvtM8Kqeyd/6Q6KyNABrVFv86x9U2K6GTpjlzRz0OJm BdebjlA7mut4uGSBHvLAXcLeJXZ36otVUVu3+YoxS6t+50Kjg8V07uNNFt2K/X+TmM1R Sg3cVU+pEG9X0jPHRIYqmrUIe77AT+k+Aw2wx6a7k0YuMgcqPkwi30UFCDvmgfqHCQMU kEkqx6MMWAfkjSYblj9WBsiaxiubGiUnikrWLWDq04YM6nTVKGt8QpnGy08ApG/pbTZq lyNQ==
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; bh=ZdV+rjclpUxE5VXDpqJsyBoeJOByvOH6+dS7uJqKgh4=; b=PGL0db7DAXCapLvW6qbXRwm/8TXyZBHV7MnC6Pxa7An7iIQ3KRzgm0CN8iY2tBrEKW pmeeaK1YEmoRMoEs03u1DyG4Tzg7j+O//HSB6ey9nhRQc4hpRcbL/EOS/87hjtOR9b2k IXWJUBwW8aBeciBqRYiWJSbE0XRiui4nVlCOUfqa+wo0FgGDeM1qlld8/qpmNySUl1Hw wXQu4lRH0NlJAV6/43BCkz0/7vMd+2OsnWM+M3s+NFgQa1Tk1Z/WCLrXQo8I3PBoeKhK u26tJygLfvvPq36onQ6qnJ6LWKAB6kk/i414WOY7X4ahf/ai9HCc2fr4Cdfn4/z/Gxkz lREw==
X-Gm-Message-State: ALyK8tJzWc0c1KpAmNIkiJCoYNsrdml00S2GJADORAfzn9j3VIfTJOKROC5/fPa6vwTgLzO2q0QZEUPxC6iyDA==
X-Received: by 10.176.67.4 with SMTP id k4mr22245364uak.47.1468972524605; Tue, 19 Jul 2016 16:55:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Tue, 19 Jul 2016 16:55:23 -0700 (PDT)
In-Reply-To: <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>
References:   <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>
From: Andy Bierman 
Date: Tue, 19 Jul 2016 16:55:23 -0700
Message-ID: 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=94eb2c09507a83abd3053805d12d
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jul 2016 23:55:28 -0000

--94eb2c09507a83abd3053805d12d
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 19, 2016 at 3:36 PM, Robert Wilton  wrote:

>
>
> On 19/07/2016 15:48, Juergen Schoenwaelder wrote:
>
>> On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:
>>
>>>     Hello Jan,
>>>
>>>     As I don't see a way to kill NP containers (my first wish) I agree
>>> they
>>>     should be clarified.  Currently the RFC says:
>>>
>>>     "If a container does not have a "presence" statement and the last
>>>        child node is deleted, the NETCONF server MAY delete the
>>> container."
>>>
>>> Having to track whether a container was created to be empty or whether
>> it just became empty seems like additional complexity for no real
>> value. I think the text should likely have said:
>>
>>     "If a container does not have a "presence" statement and the container
>>      has no child nodes, the NETCONF server MAY delete the container."
>>
>> The whole problem can be easily prevented by having clients sending
>> edit-configs that do not rely on a server maintaining empty containers.
>>
> +1.
>
> But I also agree with Balazs that YANG "must" statements on a np container
> are a bit horrible - intuitively I think that I would prefer that they are
> only bound to schema nodes that can actually contain information.  But that
> ship has already sailed ...
>
>
I find the new YANG 1.1 additions to NETCONF mostly horrible,
but this is one of the worst. This is not a backward-compatible change
from YANG 1.0 where must-stmt is only run if the container exists.
Our YANG 1.0 compliant code does not run the must-test unless the
context node (NP container) exists.

We also NEVER magically delete anything from the client.
This would be really bad in the candidate designed to support
incremental edits.

I am strongly opposed to this change in NETCONF datastore behavior
defined in the YANG language. It is not intuitive that the must-stmts
in NP containers are always checked (unless of course any
ancestor-or-self nodes contain a false when-stmt or if-feature)





> Rob
>
>
>> /js
>>
>>
>
Andy


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

--94eb2c09507a83abd3053805d12d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 19, 2016 at 3:36 PM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:




On 19/07/2016 15:48, Juergen Schoenwaelder wrote:



On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:



=C2=A0 =C2=A0 Hello Jan,



=C2=A0 =C2=A0 As I don't see a way to kill NP containers (my first wish=
) I agree they

=C2=A0 =C2=A0 should be clarified.=C2=A0 Currently the RFC says:



=C2=A0 =C2=A0 "If a container does not have a "presence" sta=
tement and the last

=C2=A0 =C2=A0 =C2=A0 =C2=A0child node is deleted, the NETCONF server MAY de=
lete the container."





Having to track whether a container was created to be empty or whether

it just became empty seems like additional complexity for no real

value. I think the text should likely have said:



=C2=A0 =C2=A0 "If a container does not have a "presence" sta=
tement and the container

=C2=A0 =C2=A0 =C2=A0has no child nodes, the NETCONF server MAY delete the c=
ontainer."



The whole problem can be easily prevented by having clients sending

edit-configs that do not rely on a server maintaining empty containers.



+1.



But I also agree with Balazs that YANG "must" statements on a np =
container are a bit horrible - intuitively I think that I would prefer that=
 they are only bound to schema nodes that can actually contain information.=
=C2=A0 But that ship has already sailed ...



I find the new YANG 1.1 additions to N=
ETCONF mostly horrible,
but this is one of the worst. This is not=
 a backward-compatible change
from YANG 1.0 where must-stmt is on=
ly run if the container exists.
Our YANG 1.0 compliant code does =
not run the must-test unless the
context node (NP container) exis=
ts.

We also NEVER magically delete anything from t=
he client.
This would be really bad in the candidate designed to =
support
incremental edits.

I am strongly=
 opposed to this change in NETCONF datastore behavior
defined in =
the YANG language. It is not intuitive that the must-stmts
in NP =
containers are always checked (unless of course any
ancestor-or-s=
elf nodes contain a false when-stmt or if-feature)



=C2=A0

Rob







/js







Andy
=C2=A0

_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf





--94eb2c09507a83abd3053805d12d--


From nobody Tue Jul 19 20:48:52 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5738212D9E3 for ; Tue, 19 Jul 2016 20:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG4Y09dk2DKS for ; Tue, 19 Jul 2016 20:48:48 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2261312D89A for ; Tue, 19 Jul 2016 20:48:48 -0700 (PDT)
Received: by mail-pa0-x232.google.com with SMTP id ks6so13660676pab.0 for ; Tue, 19 Jul 2016 20:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=6MiMosM3CtgBX4NvcU/9Ianf93EoXI42seMr4zwt7As=; b=RXR2Uy08fNt82xc7Vce34mIZqpqcrztM1O9T2xOuf6Gh9Pq1rBTP2JEBbcCnbo+/bH NgGJZLdZb8Z1MgZFNe7Wr8kzt1JePfRS9o5rSUvc5u1yv3W07GNAuNxiwpa74oXuvdNa S2XSY+2cHeYA0DBkSDBBojVmMLIv3DcG89FqZSfOvoW4ssygsoXZ2J5sk97lMbpwDlcM uqu1NzXPFl23OeBaIidjdW09nJPjegF2WyFNiPJdxY6tVkAGWK14ojqWRjYSoWO7KxKE vgisl0FDKblvna0qD1oUxF1uzklI5KCeu/GTztqrb1S/D+PQCayft72dAVRwD8rPMALz kQ0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6MiMosM3CtgBX4NvcU/9Ianf93EoXI42seMr4zwt7As=; b=lVzUBBc+WP8oXFAY29suLmdwEEDT7pOi9h2QCrGNSldkwT7puanhac6kDzvbIHJzCD 0FIjRvp/VjcK9csGHv86kQw4VyS5AUPGYByWObJLwPcKt43nVf4OELWH0c8MOkjQ1gUx /FvgKldjDAVdaStBgZx6C2FEikszaxjZa+TrgNMdq6Bp1kiHm4aE5uHcBM5cV/QES5j2 ZG+Tkxg6nchD1VPMhK8NG6p76js+fAu+9CrjavslRKRAOaFMBMI6s2WQaWEZXD+wWOod DkO0w2GkMyMfVaBOw3v5thrl2WmJNkh98/3a8MJ3Tuq7CnNPrrtYITVqcPgNgBWgoIQA QzCw==
X-Gm-Message-State: ALyK8tJZUX/CUkwLzDYXFw0LfhUJyOSBwz1FEResTFjbZnDtRZgW229SYVSuxutEX6D+Ng==
X-Received: by 10.66.232.136 with SMTP id to8mr72378212pac.130.1468986527684;  Tue, 19 Jul 2016 20:48:47 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1003::225? ([2001:420:c0c8:1003::225]) by smtp.gmail.com with ESMTPSA id z127sm606402pfz.20.2016.07.19.20.48.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Jul 2016 20:48:46 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_85B57018-2B88-41CE-9598-64B2FCE85D10"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Wed, 20 Jul 2016 05:48:44 +0200
Message-Id: 
References:   <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 03:48:50 -0000

--Apple-Mail=_85B57018-2B88-41CE-9598-64B2FCE85D10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Based on the responses, here is what I can seem to summarize.

1). The current text around NP containers is not helpful. Balasz, do you =
want to write the errata? I like Juergen=E2=80=99s suggestion

  "If a container does not have a "presence" statement and the container
   has no child nodes, the NETCONF server MAY delete the container.=E2=80=9D=


2) Add Jan=E2=80=99s table with clarifications that Balazs has requested =
on the YANG wiki.

3) Add a guidance on the wiki that client should not send requests that =
rely on a server maintaining empty containers.

> On Jul 20, 2016, at 1:55 AM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Tue, Jul 19, 2016 at 3:36 PM, Robert Wilton > wrote:
>=20
>=20
> On 19/07/2016 15:48, Juergen Schoenwaelder wrote:
> On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:
>     Hello Jan,
>=20
>     As I don't see a way to kill NP containers (my first wish) I agree =
they
>     should be clarified.  Currently the RFC says:
>=20
>     "If a container does not have a "presence" statement and the last
>        child node is deleted, the NETCONF server MAY delete the =
container."
>=20
> Having to track whether a container was created to be empty or whether
> it just became empty seems like additional complexity for no real
> value. I think the text should likely have said:
>=20
>     "If a container does not have a "presence" statement and the =
container
>      has no child nodes, the NETCONF server MAY delete the container."
>=20
> The whole problem can be easily prevented by having clients sending
> edit-configs that do not rely on a server maintaining empty =
containers.
> +1.
>=20
> But I also agree with Balazs that YANG "must" statements on a np =
container are a bit horrible - intuitively I think that I would prefer =
that they are only bound to schema nodes that can actually contain =
information.  But that ship has already sailed ...
>=20
>=20
> I find the new YANG 1.1 additions to NETCONF mostly horrible,
> but this is one of the worst. This is not a backward-compatible change
> from YANG 1.0 where must-stmt is only run if the container exists.
> Our YANG 1.0 compliant code does not run the must-test unless the
> context node (NP container) exists.
>=20
> We also NEVER magically delete anything from the client.
> This would be really bad in the candidate designed to support
> incremental edits.
>=20
> I am strongly opposed to this change in NETCONF datastore behavior
> defined in the YANG language. It is not intuitive that the must-stmts
> in NP containers are always checked (unless of course any
> ancestor-or-self nodes contain a false when-stmt or if-feature)
>=20
>=20
>=20
> =20
> Rob
>=20
>=20
> /js
>=20
>=20
>=20
> Andy
> =20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_85B57018-2B88-41CE-9598-64B2FCE85D10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Based on the responses, here is what I can seem to =
summarize.

1). The =
current text around NP containers is not helpful. Balasz, do you want to =
write the errata? I like Juergen=E2=80=99s suggestion

  "If a =
container does not have a "presence" statement and the container
   has no child nodes, the NETCONF server MAY =
delete the container.=E2=80=9D

2) Add Jan=E2=80=99s table with =
clarifications that Balazs has requested on the YANG wiki.

3) Add a guidance on the =
wiki that client should not send requests that rely on a server =
maintaining empty containers.

On =
Jul 20, 2016, at 1:55 AM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Tue, Jul 19, 2016 at 3:36 PM, =
Robert Wilton <rwilton@cisco.com> wrote:


On 19/07/2016 15:48, Juergen Schoenwaelder wrote:
On Tue, Jul 19, 2016 =
at 03:12:36PM +0200, Balazs Lengyel wrote:
    Hello Jan,

    As I don't see a way to =
kill NP containers (my first wish) I agree they
  =
  should be =
clarified.  Currently the RFC says:

    "If a container does not =
have a "presence" statement and the last
    =
   child node is deleted, the NETCONF server MAY delete the =
container."

Having to track =
whether a container was created to be empty or whether
it =
just became empty seems like additional complexity for no real
value. I think the text should likely have said:

    "If a container does not =
have a "presence" statement and the container
  =
   has no child nodes, the NETCONF server MAY delete the =
container."

The whole problem can be easily =
prevented by having clients sending
edit-configs that do =
not rely on a server maintaining empty containers.
+1.

But I also =
agree with Balazs that YANG "must" statements on a np container are a =
bit horrible - intuitively I think that I would prefer that they are =
only bound to schema nodes that can actually contain information.  =
But that ship has already sailed ...


I find the new YANG 1.1 additions to NETCONF mostly =
horrible,
but this is one of the worst. This is not =
a backward-compatible change
from YANG 1.0 where =
must-stmt is only run if the container exists.
Our =
YANG 1.0 compliant code does not run the must-test unless the
context node (NP container) exists.

We also NEVER magically delete anything =
from the client.
This would be really bad in the =
candidate designed to support
incremental =
edits.

I am =
strongly opposed to this change in NETCONF datastore behavior
defined in the YANG language. It is not intuitive that the =
must-stmts
in NP containers are always checked =
(unless of course any
ancestor-or-self nodes =
contain a false when-stmt or if-feature)



 
Rob


/js



Andy
 
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_85B57018-2B88-41CE-9598-64B2FCE85D10--


From nobody Tue Jul 19 21:10:08 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1D012D9FA for ; Tue, 19 Jul 2016 21:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b780rVzYz93e for ; Tue, 19 Jul 2016 21:10:05 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFB612D9EE for ; Tue, 19 Jul 2016 21:09:49 -0700 (PDT)
Received: from [10.243.85.200] (unknown [193.43.158.229]) by mail.tail-f.com (Postfix) with ESMTPSA id 1798E1AE0198; Wed, 20 Jul 2016 06:09:33 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A043C144-C6DE-485D-8B40-2A8F1812C8A3"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com>
Date: Wed, 20 Jul 2016 06:09:32 +0200
Message-Id: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 04:10:07 -0000

--Apple-Mail=_A043C144-C6DE-485D-8B40-2A8F1812C8A3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7B46A8C0-1C78-4214-A63E-2842F1B8BB62"


--Apple-Mail=_7B46A8C0-1C78-4214-A63E-2842F1B8BB62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Balazs,
> + 1 or more like +++1000  I always fought against them.
>=20
> The added value NP containers have compared to P containers is very =
low.
> The added complication is very high. A whole new concept of =
existing/disappearing data node is introduced, with many special rules, =
some of which are still not clear.
>=20
Aren't you exaggerating a little? NP containers are essential for making =
YANG models that resemble the existing CLI structures. Look at all the =
models already in RFC and at all the drafts. I had a look in the IETF =
DRAFTS folder, and around 20% of the objects defined were NP containers. =
Far less than 1% were P containers. It seems then that modelers find NP =
containers more useful than you do.

NP containers are actually really simple, trivial even, but of course =
it's always complicated to implement something that isn't fully =
understood.
> As I don't see a way to kill NP containers (my first wish) I agree =
they should be clarified.  Currently the RFC says:
> "If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the =
container."
> This allows deleting only when the last child node is deleted. It does =
not allow deleting an NP container after an explicit create.
>=20
For some reason you're hung up about the "creation" and "deletion" of NP =
containers. I maintain that NP containers can't really be created and =
deleted in a deeper sense of the word. They have zero bits of =
information, so a conforming implementation cannot remember their =
history, and they have no value. There are no moving parts here.

If it makes it easier, think of NP containers as a prefix to the name of =
all the objects inside the container.
> Your table does not directly answer some key questions for me:
>=20
> Q1) Is it allowed to create it explicitly? Yes/No?
>=20
NP containers cannot be created, not in the sense that you can ask about =
their created/not-created state later, anyway. They are mentioned in =
edit-config operations, since there is no way to refer to objects inside =
the containers without mentioning the container name. The NP container =
itself isn't an object that has an existence property in itself, so =
asking whether it can be created is moot.
> Q2) Is it allowed to create it, then create it again? For a P =
container this would result in a create-failed. For NP, allowed or no?
>=20
You can include an NP container in an edit-config create call as many =
times as you like. "Creation" of an NP container can never result in =
create-failed. NP containers have zero bits of information, so we have =
no memory of whether it has been previously created or not. It's =
completely uninteresting.
> Q3) If it is allowed to create them, will they exist and continue to =
exist in the database, or can the server delete them any time?
>=20
They do not exist in the database, other than as path prefixes to the =
objects inside the container. Whether empty NP containers are returned =
in a get-config operation is an implementation decision, and has nothing =
to do with previous "create" or "delete" calls.
> Q4) Does the NP container modify the behavior of edit-config none? =
Should we fail or succeed in the provided examples? Yes/No?
>=20
There were a number of examples provided. Some should fail, some =
succeed. In the recent examples named by letters a-f, I think it was =
only example c and f that should succeed. Refer back to that thread for =
details. If you had some other example in mind, please be specific.
> Q5) When are must statements that are direct substatements of an NP =
container validated? Following your logic IMHO such must statements MUST =
NOT be allowed in YANG at all.  If an NP container has no meaning why do =
we connect checks to them?
>=20
The must statement(s) in an NP container must be validated for each =
parent node that the container exists in, e.g. for each list instance if =
the NP container sits in a list. The same applies for P containers, once =
they are created.
> I propose to write an errata about this immediately after the YANG 1.1 =
RFC comes out.
>=20
What do you propose to say in the errata?

/jan

>>>> (f) should be accepted without an error IMO.
>>>=20
>>> Ok. If f) is accepted then it indicates the server chooses to delete =
an empty container
>>> or it basically ignore the operation to create only a NP container =
node.
>>=20
>> I agree with this.
>>=20
>> I also agree that RFC 6020 could spell this out in a more direct way. =
Currently the description of NP and P containers does not contain a =
table with the properties of each, but instead enumerates how P =
containers differ from NP containers in plain english. In order to build =
a such a table, I've collected quotes on each type here:
>>=20
>> P-container qoutes:
>> - "presence in the configuration has an explicit meaning"
>> - "presence of the container itself is configuration data"
>> - "representing a single bit of configuration data"
>> - "These containers are explicitly created and deleted"
>> - "The "presence" statement assigns a meaning to the presence of a =
container in the data tree"
>>=20
>> NP-container qoutes:
>> - "exist only for organizing the hierarchy of data nodes"
>> - "container has no meaning of its own, existing only to contain =
child nodes"
>> - "the container is used to give some structure to the data, and it =
carries no meaning by itself"
>> - "MAY choose not to send a container element if the container node =
does not have the "presence" statement and no child nodes exist"
>> - "a client ... must be prepared to handle the case that a container =
node without a "presence" statement is not present"
>>=20
>> Based on the above quotes, I believe this to be a fair description of =
the P and NP container differences in a tabular form:
>>=20
>>                                   | P-container | NP-container |
>> ----------------------------------+-------------+--------------+
>> Organizing the hierarchy          |      Y      |       Y      |
>> May have child nodes              |      Y      |       Y      |
>> Existence has meaning             |      Y      |       N      |
>> Is configuration data             |      Y      |       N      |
>> Information content               |    1 bit    |    0 bits    |
>> Explicitly created and deleted    |      Y      |       N      |
>> Suppress when empty               |      N      |      MAY     |
>> ----------------------------------+-------------+--------------+
>>=20
>> With this background, I consider it clear that "creation" and =
"deletion" of P-containers has no effect on the configuration. In fact, =
a conforming implementation cannot even remember/know if a P-container =
has been created or not since it has zero bits of information. =
P-containers aren't really configuration data, even if they may be =
located in the config true part of the world.
>>=20
>> If anyone sees anything wrong, unfounded or unclear with the table =
above, I think it would be of high general interest that this is pointed =
out asap.
>>=20
>> /jan
>>=20
>>=20
>>=20
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netconf =

>=20
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com 


--Apple-Mail=_7B46A8C0-1C78-4214-A63E-2842F1B8BB62
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=windows-1252

Balazs,
+ 1 or more like +++1000  I always fought against them.
The added value NP containers have compared to P containers is very low. 
The added complication is very high. A whole new concept of existing/disappearing data node is introduced, with many special rules, some of which are still not clear.


Aren't you exaggerating a little? NP containers are essential for making YANG models that resemble the existing CLI structures. Look at all the models already in RFC and at all the drafts. I had a look in the IETF DRAFTS folder, and around 20% of the objects defined were NP containers. Far less than 1% were P containers. It seems then that modelers find NP containers more useful than you do.

NP containers are actually really simple, trivial even, but of course it's always complicated to implement something that isn't fully understood.
As I don't see a way to kill NP containers (my first wish) I
      agree they should be clarified.  Currently the RFC says: 

    
"If a container does not have a "presence" statement and the last

         child node is deleted, the NETCONF server MAY delete the
      container." 

    
This allows deleting only when the last child node is deleted. It
      does not allow deleting an NP container after an explicit create.
For some reason you're hung up about the "creation" and "deletion" of NP containers. I maintain that NP containers can't really be created and deleted in a deeper sense of the word. They have zero bits of information, so a conforming implementation cannot remember their history, and they have no value. There are no moving parts here.

If it makes it easier, think of NP containers as a prefix to the name of all the objects inside the container.

    
Your table does not directly answer some key questions for me:
Q1) Is it allowed to create it explicitly? Yes/No?
NP containers cannot be created, not in the sense that you can ask about their created/not-created state later, anyway. They are mentioned in edit-config operations, since there is no way to refer to objects inside the containers without mentioning the container name. The NP container itself isn't an object that has an existence property in itself, so asking whether it can be created is moot.

      Q2) Is it allowed to create it, then create it again? For a P
      container this would result in a create-failed. For NP, allowed or
      no?
You can include an NP container in an edit-config create call as many times as you like. "Creation" of an NP container can never result in create-failed. NP containers have zero bits of information, so we have no memory of whether it has been previously created or not. It's completely uninteresting.

      Q3) If it is allowed to create them, will they exist and continue
      to exist in the database, or can the server delete them any time?
They do not exist in the database, other than as path prefixes to the objects inside the container. Whether empty NP containers are returned in a get-config operation is an implementation decision, and has nothing to do with previous "create" or "delete" calls.

      Q4) Does the NP container modify the behavior of edit-config none?
      Should we fail or succeed in the provided examples? Yes/No?
There were a number of examples provided. Some should fail, some succeed. In the recent examples named by letters a-f, I think it was only example c and f that should succeed. Refer back to that thread for details. If you had some other example in mind, please be specific.

      Q5) When are must statements that are direct substatements of an
      NP container validated? Following your logic IMHO such must
      statements MUST NOT be allowed in YANG at all.  If an NP container
      has no meaning why do we connect checks to them?
The must statement(s) in an NP container must be validated for each parent node that the container exists in, e.g. for each list instance if the NP container sits in a list. The same applies for P containers, once they are created.
I propose to write an errata about this immediately after the
      YANG 1.1 RFC comes out.
What do you propose to say in the errata?

/jan


    

      
      

        

          

            

              

                
(f) should be accepted without an error
                    IMO.  

                  

              

            

            

            Ok. If f) is accepted then it
              indicates the server chooses to delete an empty container

            or it basically ignore the operation
              to create only a NP container node.

          

        

        


        

        
I agree with this.

        


        

        
I also agree that RFC 6020 could spell this out in a more
          direct way. Currently the description of NP and P containers
          does not contain a table with the properties of each, but
          instead enumerates how P containers differ from NP containers
          in plain english. In order to build a such a table, I've
          collected quotes on each type here:

        


        

        
P-container qoutes:

        
- "presence in the configuration has an explicit meaning"

        
- "presence of the container itself is configuration data"

        
- "representing a single bit of configuration data"

        
- "These containers are explicitly created and deleted"

        
- "The "presence" statement assigns a meaning to the
          presence of a container in the data tree"

        


        

        
NP-container qoutes:

        
- "exist only for organizing the hierarchy of data nodes"

        

          
- "container has no meaning of its own, existing
            only to contain child nodes"

        

        
- "the container is used to give some structure to the
          data, and it carries no meaning by itself"

        
- "MAY choose not to send a container element if the
          container node does not have the "presence" statement and no
          child nodes exist"

        
- "a client ... must be prepared to handle the case that a
          container node without a "presence" statement is not present"

        


        

        
Based on the above quotes, I believe this to be a fair
          description of the P and NP container differences in a tabular
          form:

        


        

        
                             
                | P-container | NP-container |

        
----------------------------------+-------------+--------------+

        
Organizing the hierarchy    
                 |      Y      |       Y      |

        
May have child nodes        
                 |      Y      |       Y      |

        
Existence has meaning        
                |      Y      |       N      |

        
Is
            configuration data             |      Y      |       N    
             |

        
Information content          
                |    1 bit    |    0 bits    |

        
Explicitly created and
            deleted    |      Y      |       N      |

        
Suppress when empty          
                |      N      |      MAY     |

        

          
----------------------------------+-------------+--------------+

          


            

        

        
With this background, I consider it clear that "creation"
          and "deletion" of P-containers has no effect on the
          configuration. In fact, a conforming implementation cannot
          even remember/know if a P-container has been created or not
          since it has zero bits of information. P-containers aren't
          really configuration data, even if they may be located in the
          config true part of the world.

        


        

        
If anyone sees anything wrong, unfounded or unclear with
          the table above, I think it would be of high general interest
          that this is pointed out asap.

        


        

        
/jan

        


        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  






--Apple-Mail=_7B46A8C0-1C78-4214-A63E-2842F1B8BB62--

--Apple-Mail=_A043C144-C6DE-485D-8B40-2A8F1812C8A3
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

iQEcBAEBCgAGBQJXjvl8AAoJEBSCnbqufIisXMUH/jrgWHdcJ/57RHH7ErqP2HTl
STTwtogWFrQF9uz5/S2lw7qrQ+PLpcuST0zOeRiC0td2Pw+bjT2Af9h/aIZm7OpT
86CSkJACiC48+VwheENP2xior3PGtz63JPBpQ/r2bNUmX644u6CnAYRjRT90CvCi
4UUPNvY0Oa96NhsWa4Mdl954UqlXdRbHIPG59a28mpBcF90Jj3NsktM7s8ybEsXG
A5Q9kfc8wVdzd6q7eVErqrolcpR9K1QqGl5IwpXiBc2YtOn+/2lrjK1giStUdG1X
qasHxFabtUC9Ax/ef0Znd3IZKLdJErJrcjjhPxFsimay0F0dOcFANAtBwFzMo+A=
=/CMM
-----END PGP SIGNATURE-----

--Apple-Mail=_A043C144-C6DE-485D-8B40-2A8F1812C8A3--


From nobody Tue Jul 19 23:27:51 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3912DABA for ; Tue, 19 Jul 2016 23:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjZ8454q5e_y for ; Tue, 19 Jul 2016 23:27:48 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FF112D8A1 for ; Tue, 19 Jul 2016 23:27:47 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id n129so10562286vke.3 for ; Tue, 19 Jul 2016 23:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BQuf7lX7E3UPQNuNnZ/Whn7qgYGkmjNaAqG4XiTinOs=; b=yvFf3EiaKV/ncVC+p8RZEJtEIL6m6kaj3o+fG6hd9X+KSNa1l8/qsnAL4kJgm3aAax mYlrj8uRG2e9I9AVMoNx0g2kHPtsBOWAr4m/3ifRdSdqU1DSbQqRxn6Twb4lo8A3OXNe 4aUhG10p1esUtGWPWT/oq8v5+KtFgABU6hRYtR/Vv32u2yKwQop+uW98nrOKTmHrnVya 3k1dQQxnteIHZMty3UpCAINbhER7kBJXMj84K+Aac2Yvwf/DopfcK0OW8eItv2II8JzH h0iGWvPi5Mor81z8hC6Lp9OyJ27Z1L/TwdGAUW5b30jYvJkq9LP+sj+esoJnmwfMNX2u gvbQ==
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; bh=BQuf7lX7E3UPQNuNnZ/Whn7qgYGkmjNaAqG4XiTinOs=; b=DeTJIT07AjXCO8VN6fm31k9H2Oy1wb5qDabLn+hBV1WfbSGDoLP98QYkMGanwgxA5p 31cuU5F+qyItOzEjWw6jVr/OSirCUYkYL9iAYuzKDp8jYlVP+/GDBeNM+/JZ8ePrd8cR KF/5Q5Zdt6QWtlOPuoL2EqaLEFo/HrVrNmjqh2IsSgijmpV6pojaBCayhkOKXFlZyYSP wusyCi6cWc4un8bq9UY9kIzkpf1S3A6sbizOjHQ45kFO/TKpayRD3jrPmPFss2huwMua qpRXy+5i8/CqR+tbbrq6gvpvRFNwdhGk3VxkSE1QRdlt+yK5DWHkrZiyDXZjTa7eMEs0 SsPQ==
X-Gm-Message-State: ALyK8tK9GrZH7FvCJu8KB7vRAj/1ZF9uw3XUDTPly8c/LO99iAhVnjlbPGEdPzWEsCj3PWStWrgjx8/tbQAZ3w==
X-Received: by 10.31.70.193 with SMTP id t184mr23059068vka.123.1468996066735;  Tue, 19 Jul 2016 23:27:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Tue, 19 Jul 2016 23:27:45 -0700 (PDT)
In-Reply-To: 
References:   <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>  
From: Andy Bierman 
Date: Tue, 19 Jul 2016 23:27:45 -0700
Message-ID: 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=001a11489076bc0e8805380b4c81
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 06:27:50 -0000

--001a11489076bc0e8805380b4c81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Based on the responses, here is what I can seem to summarize.
>
> 1). The current text around NP containers is not helpful. Balasz, do you
> want to write the errata? I like Juergen=E2=80=99s suggestion
>
>   "If a container does not have a "presence" statement and the container
>    has no child nodes, the NETCONF server MAY delete the container.=E2=80=
=9D
>
> 2) Add Jan=E2=80=99s table with clarifications that Balazs has requested =
on the
> YANG wiki.
>

I object to expanding the text as specified.
IMO this behavior favors 1 implementation choice over another.

Andy


>
> 3) Add a guidance on the wiki that client should not send requests that
> rely on a server maintaining empty containers.
>
> On Jul 20, 2016, at 1:55 AM, Andy Bierman  wrote:
>
>
>
> On Tue, Jul 19, 2016 at 3:36 PM, Robert Wilton  wrote:
>
>>
>>
>> On 19/07/2016 15:48, Juergen Schoenwaelder wrote:
>>
>>> On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:
>>>
>>>>     Hello Jan,
>>>>
>>>>     As I don't see a way to kill NP containers (my first wish) I agree
>>>> they
>>>>     should be clarified.  Currently the RFC says:
>>>>
>>>>     "If a container does not have a "presence" statement and the last
>>>>        child node is deleted, the NETCONF server MAY delete the
>>>> container."
>>>>
>>>> Having to track whether a container was created to be empty or whether
>>> it just became empty seems like additional complexity for no real
>>> value. I think the text should likely have said:
>>>
>>>     "If a container does not have a "presence" statement and the
>>> container
>>>      has no child nodes, the NETCONF server MAY delete the container."
>>>
>>> The whole problem can be easily prevented by having clients sending
>>> edit-configs that do not rely on a server maintaining empty containers.
>>>
>> +1.
>>
>> But I also agree with Balazs that YANG "must" statements on a np
>> container are a bit horrible - intuitively I think that I would prefer t=
hat
>> they are only bound to schema nodes that can actually contain informatio=
n.
>> But that ship has already sailed ...
>>
>>
> I find the new YANG 1.1 additions to NETCONF mostly horrible,
> but this is one of the worst. This is not a backward-compatible change
> from YANG 1.0 where must-stmt is only run if the container exists.
> Our YANG 1.0 compliant code does not run the must-test unless the
> context node (NP container) exists.
>
> We also NEVER magically delete anything from the client.
> This would be really bad in the candidate designed to support
> incremental edits.
>
> I am strongly opposed to this change in NETCONF datastore behavior
> defined in the YANG language. It is not intuitive that the must-stmts
> in NP containers are always checked (unless of course any
> ancestor-or-self nodes contain a false when-stmt or if-feature)
>
>
>
>
>
>> Rob
>>
>>
>>> /js
>>>
>>>
>>
> Andy
>
>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>

--001a11489076bc0e8805380b4c81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani =
<mjethanand=
ani@gmail.com> wrote:
Based on the responses, here is what I can s=
eem to summarize.

1). The current text around NP contain=
ers is not helpful. Balasz, do you want to write the errata? I like Juergen=
=E2=80=99s suggestion

=C2=A0=C2=A0"If a conta=
iner does not have a "presence" statement and the container
=
=C2=A0=C2=A0=C2=A0has no child nodes, the NETCONF server MAY delete the con=
tainer.=E2=80=9D

2) Add Jan=E2=80=99s table with c=
larifications that Balazs has requested on the YANG wiki.

I object to expanding the text as specified.
IMO this behavior favors 1 implementation choice over another.
=


Andy
=C2=A0

3) Add a guidanc=
e on the wiki that client should not send requests that rely on a server ma=
intaining empty containers.

On Jul 20, 2016, at 1:55 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Jul 19, 2016 at=
 3:36 PM, Robert Wilton=C2=A0<rwilton@cisco.com>=C2=A0wrote:


On 19/07/2016 15:48,=
 Juergen Schoenwaelder wrote:
On Tue, Jul 19, 2016 at 0=
3:12:36PM +0200, Balazs Lengyel wrote:
=C2=A0 =C2=A0=C2=A0Hello Jan,

=C2=A0 =C2=A0=C2=A0As I don&=
#39;t see a way to kill NP containers (my first wish) I agree they
=C2=
=A0 =C2=A0=C2=A0should be clarified.=C2=A0 Currently the RFC s=
ays:

=C2=A0 =C2=A0=C2=A0"If a container does not h=
ave a "presence" statement and the last
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0child node is deleted, the NETCONF server MAY delete the container.&q=
uot;

Having to track whether a container was created to=
 be empty or whether
it just became empty seems like additional complexi=
ty for no real
value. I think the text should likely have said:

=
=C2=A0 =C2=A0=C2=A0"If a container does not have a "=
presence" statement and the container
=C2=A0 =C2=A0 =C2=A0has no ch=
ild nodes, the NETCONF server MAY delete the container."

The wh=
ole problem can be easily prevented by having clients sending
edit-confi=
gs that do not rely on a server maintaining empty containers.
+1.

But I also agree with Balazs that YANG "must" state=
ments on a np container are a bit horrible - intuitively I think that I wou=
ld prefer that they are only bound to schema nodes that can actually contai=
n information.=C2=A0 But that ship has already sailed ...


I find the new YANG 1.1 additions to NETCONF mostly =
horrible,
but this is one of the worst. This is not a backward-co=
mpatible change
from YANG 1.0 where must-stmt is only run if the =
container exists.
Our YANG 1.0 compliant code does not run the mu=
st-test unless the
context node (NP container) exists.
=

We also NEVER magically delete anything from the client.
This would be really bad in the candidate designed to support
<=
div>incremental edits.

I am strongly opposed to th=
is change in NETCONF datastore behavior
defined in the YANG langu=
age. It is not intuitive that the must-stmts
in NP containers are=
 always checked (unless of course any
ancestor-or-self nodes cont=
ain a false when-stmt or if-feature)



=C2=A0
Rob

=

/js



Andy
=

=C2=A0
_________________________________________=
______
Netconf mailing list
Netconf@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list<=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-wei=
ght:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px">Net=
conf@ietf.org
https://www.ietf.org/mailman/listinf=
o/netconf



Mahesh Jethanandani










--001a11489076bc0e8805380b4c81--


From nobody Tue Jul 19 23:31:07 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA43F12DAAB for ; Tue, 19 Jul 2016 23:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 UbFNKP6Gzvtm for ; Tue, 19 Jul 2016 23:31:03 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6829A12D9B9 for ; Tue, 19 Jul 2016 23:31:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 80A88654; Wed, 20 Jul 2016 08:31:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2PaymTn77Ggj; Wed, 20 Jul 2016 08:30:56 +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, 20 Jul 2016 08:30:58 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23E9220078; Wed, 20 Jul 2016 08:30:58 +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 w6M3O-t7TyTR; Wed, 20 Jul 2016 08:30:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC59020077; Wed, 20 Jul 2016 08:30:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CF5BD3BDB64D; Wed, 20 Jul 2016 08:30:54 +0200 (CEST)
Date: Wed, 20 Jul 2016 08:30:54 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20160720063054.GA51663@elstar.local>
Mail-Followup-To: Andy Bierman , Mahesh Jethanandani , Netconf 
References: <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>   
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 06:31:06 -0000

On Tue, Jul 19, 2016 at 11:27:45PM -0700, Andy Bierman wrote:
> On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
> 
> > Based on the responses, here is what I can seem to summarize.
> >
> > 1). The current text around NP containers is not helpful. Balasz, do you
> > want to write the errata? I like Juergen’s suggestion
> >
> >   "If a container does not have a "presence" statement and the container
> >    has no child nodes, the NETCONF server MAY delete the container.â€
> >
> > 2) Add Jan’s table with clarifications that Balazs has requested on the
> > YANG wiki.
> >
> 
> I object to expanding the text as specified.
> IMO this behavior favors 1 implementation choice over another.
> 

Why?

/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 Jul 19 23:50:41 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5939912D9B9 for ; Tue, 19 Jul 2016 23:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qtYoy_WbM0Q for ; Tue, 19 Jul 2016 23:50:38 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C92612B00E for ; Tue, 19 Jul 2016 23:50:38 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id w127so56425471vkh.2 for ; Tue, 19 Jul 2016 23:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vP0XfXk6w4Yfg8wgmfRwXPmiryA8EDjKYSo9nqs5f+Y=; b=l6YWbZsH4LW8PorD9Q2VFIdc0WMySyOhMEyPWacdjqFGVoOcDyiiLkSFUOS5aZs0dc Yhr5KDPptda+QaFB+TLg7zzPXKfehc0S0kaSLTugkTLRLp0ZBbjiltSsP5WEZPJcDGlQ sczkSUTZJ1VxALQKoXpinZeaTpXJolJ5oHKem82tPXXj792zrLeSLsTM3VmlCUAOvq4d iCj0y5Ihi09VowcMOC/ezYnZ3OQu0Snfmq0r/+S/siOM4Q19JlfnyEHv8JAQrq8SKhGp 1Ea/UxrfSfIcjAF7znowtLam+QoXurc9dFpmZo+AG6RqIXlJ0QLZRT08+ke5/aBt1qQZ PhlA==
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; bh=vP0XfXk6w4Yfg8wgmfRwXPmiryA8EDjKYSo9nqs5f+Y=; b=NbwFsxd0Un6f1P7t+dR21sid2WoxMHsvxGXKLqVLXGhQGpweag8tvGPwd/T1aUAHBN daS9Wx+73dX06ndFWRWujg2j+TrHNEThrkMB8VZ5O6mmx25cQGuZTuk/5royK9wfK54c /8huWsC6W0ozS6tYBUHvflIn9Wr0uPuE5QEZp1uHBea77ZOHM4QRxFWbSAl+HGsAx/Xu MMM6od1fGm5avIENe7jKCzAzfLy4AlhieeJK7cUlln68Ra9JIj4eO3TqYqromN+e7A2W oUsh3aKykBlb7s4p1gOFr9FKLWnsDAZcJeouTURuGuWbK1i7xQGOmnKuzVgy9DcG/NeU qQRQ==
X-Gm-Message-State: ALyK8tIOtph/T62fOKOiqQOzqFDWHuqjAM7b5Z4xslDYd1lnaoNfQLL4XmbgzCDeUgGoLqEzvpgzjSwXed6sWw==
X-Received: by 10.176.69.210 with SMTP id u76mr12666167uau.16.1468997437249; Tue, 19 Jul 2016 23:50:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Tue, 19 Jul 2016 23:50:36 -0700 (PDT)
In-Reply-To: <20160720063054.GA51663@elstar.local>
References: <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>    <20160720063054.GA51663@elstar.local>
From: Andy Bierman 
Date: Tue, 19 Jul 2016 23:50:36 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Mahesh Jethanandani , Netconf 
Content-Type: multipart/alternative; boundary=94eb2c11c3046c729b05380b9ef9
Archived-At: 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 06:50:40 -0000

--94eb2c11c3046c729b05380b9ef9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2016 at 11:30 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Jul 19, 2016 at 11:27:45PM -0700, Andy Bierman wrote:
> > On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani <
> > mjethanandani@gmail.com> wrote:
> >
> > > Based on the responses, here is what I can seem to summarize.
> > >
> > > 1). The current text around NP containers is not helpful. Balasz, do
> you
> > > want to write the errata? I like Juergen=E2=80=99s suggestion
> > >
> > >   "If a container does not have a "presence" statement and the
> container
> > >    has no child nodes, the NETCONF server MAY delete the container.=
=E2=80=9D
> > >
> > > 2) Add Jan=E2=80=99s table with clarifications that Balazs has reques=
ted on the
> > > YANG wiki.
> > >
> >
> > I object to expanding the text as specified.
> > IMO this behavior favors 1 implementation choice over another.
> >
>
> Why?
>

because implementation is non-trivial regardless what tail-f says.
One can also decide to remove the text about MAY delete
an NP container after the last child is deleted.

The text about default-operation=3Dnone is in RFC 6241 not this draft.
That document does not say anything about ignoring the error conditions
for "none".

Also, the text only affects the NETCONF  operation.
So you want this change? Fine.  It does not apply to RESTCONF
or NETCONF .

I also strongly object to significant design changes being made
as errata.  Pull the document back into the WG to make these changes.




>
> /js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--94eb2c11c3046c729b05380b9ef9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 19, 2016 at 11:30 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jul 19, 2016 at 11:27:45PM -0700, Andy Bier=
man wrote:

> On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani <

> mjethanandani@gmail.com=
> wrote:

>

> > Based on the responses, here is what I can seem to summarize.

> >

> > 1). The current text around NP containers is not helpful. Balasz,=
 do you

> > want to write the errata? I like Juergen=E2=80=99s suggestion

> >

> >=C2=A0 =C2=A0"If a container does not have a "presence&q=
uot; statement and the container

> >=C2=A0 =C2=A0 has no child nodes, the NETCONF server MAY delete th=
e container.=E2=80=9D

> >

> > 2) Add Jan=E2=80=99s table with clarifications that Balazs has re=
quested on the

> > YANG wiki.

> >

>

> I object to expanding the text as specified.

> IMO this behavior favors 1 implementation choice over another.

>



Why?

because implementation is non-triv=
ial regardless what tail-f says.
One can also decide to remove th=
e text about MAY delete
an NP container after the last child is d=
eleted.

The text about default-operation=3Dnone is=
 in RFC 6241 not this draft.
That document does not say anything =
about ignoring the error conditions
for "none".

Also, the text only affects the NETCONF <edit-config&g=
t; operation.
So you want this change? Fine.=C2=A0 It does not ap=
ply to RESTCONF
or NETCONF <copy-config>.

I also strongly object to significant design changes being made
as errata.=C2=A0 Pull the document back into the WG to make these ch=
anges.


=C2=A0



/js

Andy
=C2=A0=




--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--94eb2c11c3046c729b05380b9ef9--


From nobody Wed Jul 20 03:37:57 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4DA12B012 for ; Wed, 20 Jul 2016 03:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 g-bPRrUfI3A5 for ; Wed, 20 Jul 2016 03:37:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5047E12D58D for ; Wed, 20 Jul 2016 03:37:52 -0700 (PDT)
Received: from [192.168.1.108] (h118n5-haes-a12.ias.bredband.telia.com [217.209.174.118]) by mail.tail-f.com (Postfix) with ESMTPSA id DD00E1AE012C; Wed, 20 Jul 2016 12:37:50 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D432A89D-32DF-40EC-98FC-94580FDA09E7"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: 
Date: Wed, 20 Jul 2016 12:37:50 +0200
Message-Id: <682D8131-8E07-43E8-9942-29C70F7683A8@tail-f.com>
References: <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>    <20160720063054.GA51663@elstar.local> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 10:37:55 -0000

--Apple-Mail=_D432A89D-32DF-40EC-98FC-94580FDA09E7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D0ABFB6B-8616-4A2C-90E6-78BF81BE4A12"


--Apple-Mail=_D0ABFB6B-8616-4A2C-90E6-78BF81BE4A12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Andy,

> I find the new YANG 1.1 additions to NETCONF mostly horrible,
> but this is one of the worst. This is not a backward-compatible change
> from YANG 1.0 where must-stmt is only run if the container exists.
> Our YANG 1.0 compliant code does not run the must-test unless the
> context node (NP container) exists.

I'm not referring to anything new at all. All the quotes I collected on =
how NP and P containers work were actually from RFC6020/YANG 1.0.

> We also NEVER magically delete anything from the client.
> This would be really bad in the candidate designed to support
> incremental edits.

Magically deleting stuff would indeed increase the complexity on both =
sides, even if this could be tolerable if well described and had good =
reasons. I don't think this pertains to NP containers, though. Here =
we're talking about a rock with no moving parts. Zero bits of =
information. NP containers cannot be created and deleted in the =
traditional sense of the word. Whether they are reported does not depend =
on whether they were part of a previous "create" or "delete".

It would of course be best if you could describe how you interpret =
proper NP container behavior yourself, perhaps based on a table similar =
to what I presented? To me it appears that you want NP and P containers =
to behave the same way. Is that correct? If so, what language is this =
view founded on? I haven't seen any comments from you on the table I put =
together. Is it correct, or are there things to debate about it?

> I am strongly opposed to this change in NETCONF datastore behavior
> defined in the YANG language. It is not intuitive that the must-stmts
> in NP containers are always checked (unless of course any
> ancestor-or-self nodes contain a false when-stmt or if-feature)

I don't think this is a change, and I find it highly intuitive that must =
statements in NP containers are checked if the parent node exists.

I think of NP containers as path prefixes of the objects inside, and =
with that I see a coherent picture.

> > > Based on the responses, here is what I can seem to summarize.
> > >
> > > 1). The current text around NP containers is not helpful. Balasz, =
do you
> > > want to write the errata? I like Juergen=E2=80=99s suggestion
> > >
> > >   "If a container does not have a "presence" statement and the =
container
> > >    has no child nodes, the NETCONF server MAY delete the =
container.=E2=80=9D
> > >
> > > 2) Add Jan=E2=80=99s table with clarifications that Balazs has =
requested on the
> > > YANG wiki.
> > >
> >
> > I object to expanding the text as specified.
> > IMO this behavior favors 1 implementation choice over another.
> >
>=20
> Why?
>=20
> because implementation is non-trivial regardless what tail-f says.
> One can also decide to remove the text about MAY delete
> an NP container after the last child is deleted.

=46rom an implementation perspective I don't think it's a big deal to go =
from one to the other. It would be trivial to change the implementation =
to always report the empty NP containers, but I really don't see the =
value with this. The server would get a little chattier, what's the =
point?

Of course it's a little annoying to change the specs in a non-backwards =
compatible way. We would need strong reasons to do that.

In the end, what matters is not the server implementations. Regardless =
what you say, they can be changed. The important thing is what makes =
sense for users, i.e. for modelers and at runtime/on the wire.

> The text about default-operation=3Dnone is in RFC 6241 not this draft.
> That document does not say anything about ignoring the error =
conditions
> for "none".

I think it's our differing views of what an NP container "is" that is at =
the root of this. With the view that NP containers are path prefixes, =
this becomes a non-issue.

> Also, the text only affects the NETCONF  operation.
> So you want this change? Fine.  It does not apply to RESTCONF
> or NETCONF .

If you could describe how NP and P containers differ, I think everything =
else would fall out after that.

> I also strongly object to significant design changes being made
> as errata.  Pull the document back into the WG to make these changes.

I agree significant design changes shouldn't be made as errata. I don't =
see any design changes in this case, though. Since we've had this pretty =
long conversation, clarifying the text one way or another is probably a =
good idea. I don't oppose opening up the document to do so.

/jan


--Apple-Mail=_D0ABFB6B-8616-4A2C-90E6-78BF81BE4A12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Andy,

I =
find the new YANG 1.1 additions to NETCONF mostly horrible,
but this is one of =
the worst. This is not a backward-compatible change
from YANG 1.0 where =
must-stmt is only run if the container exists.
Our YANG 1.0 =
compliant code does not run the must-test unless the
context node (NP =
container) exists.

I'm not referring to anything new at =
all. All the quotes I collected on how NP and P containers work were =
actually from RFC6020/YANG 1.0.

We also NEVER =
magically delete anything from the client.
This would be really bad in the =
candidate designed to support
incremental =
edits.

Magically deleting stuff would indeed increase the complexity =
on both sides, even if this could be tolerable if well described and had =
good reasons. I don't think this pertains to NP containers, though. Here =
we're talking about a rock with no moving parts. Zero bits of =
information. NP containers cannot be created and deleted in the =
traditional sense of the word. Whether they are reported does not depend =
on whether they were part of a previous "create" or "delete".

It would of course be =
best if you could describe how you interpret proper NP container =
behavior yourself, perhaps based on a table similar to what I presented? =
To me it appears that you want NP and P containers to behave the same =
way. Is that correct? If so, what language is this view founded on? I =
haven't seen any comments from you on the table I put together. Is it =
correct, or are there things to debate about it?

I am strongly =
opposed to this change in NETCONF datastore behavior
defined in the YANG =
language. It is not intuitive that the must-stmts
in NP containers =
are always checked (unless of course any
ancestor-or-self nodes contain a false =
when-stmt or if-feature)

I don't think this is a change, and I =
find it highly intuitive that must statements in NP containers are =
checked if the parent node exists. 

I think of NP containers as path =
prefixes of the objects inside, and with that I see a coherent =
picture.

> > Based on =
the responses, here is what I can seem to summarize.

> >

> > 1). The current text around NP containers is not helpful. =
Balasz, do you

> > want to write the errata? I like Juergen=E2=80=99s =
suggestion

> >

> >   "If a container does not have a "presence" =
statement and the container

> >    has no child nodes, the NETCONF server MAY delete =
the container.=E2=80=9D

> >

> > 2) Add Jan=E2=80=99s table with clarifications that Balazs has =
requested on the

> > YANG wiki.

> >

>

> I object to expanding the text as specified.

> IMO this behavior favors 1 implementation choice over another.

>



Why?

because implementation is non-trivial regardless what tail-f =
says.
One can also decide to remove the text about =
MAY delete
an NP container after the last child is =
deleted.

=46rom an implementation perspective I don't think =
it's a big deal to go from one to the other. It would be trivial to =
change the implementation to always report the empty NP containers, but =
I really don't see the value with this. The server would get a little =
chattier, what's the point? 

Of =
course it's a little annoying to change the specs in a non-backwards =
compatible way. We would need strong reasons to do that.

In the end, what matters is not the server =
implementations. Regardless what you say, they can be changed. The =
important thing is what makes sense for users, i.e. for modelers and at =
runtime/on the wire.

The =
text about default-operation=3Dnone is in RFC 6241 not this =
draft.
That document does not say anything about =
ignoring the error conditions
for =
"none".

I think it's our differing views of what an NP =
container "is" that is at the root of this. With the view that NP =
containers are path prefixes, this becomes a non-issue.

Also, the text only affects the =
NETCONF <edit-config> operation.
So you want =
this change? Fine.  It does not apply to RESTCONF
or NETCONF =
<copy-config>.

If you could describe how NP and P containers =
differ, I think everything else would fall out after that.

I also strongly object to =
significant design changes being made
as =
errata.  Pull the document back into the WG to make these =
changes.

I agree significant design changes shouldn't be =
made as errata. I don't see any design changes in this case, though. =
Since we've had this pretty long conversation, clarifying the text one =
way or another is probably a good idea. I don't oppose opening up the =
document to do so.

/jan

=

--Apple-Mail=_D0ABFB6B-8616-4A2C-90E6-78BF81BE4A12--

--Apple-Mail=_D432A89D-32DF-40EC-98FC-94580FDA09E7
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

iQEcBAEBCgAGBQJXj1R+AAoJEBSCnbqufIisVXIH/30r0vvtN202DQBsSfPKf85w
jVeCXKbbU27ih+5nPGO2gotyTvdRrrhqClEtRCzqTM79HELfV3wDVOj8fap4OUWd
55UCgMkITTLJOfIYMBqjYVpvmsI2zLnofJFH0En9idiS2zklloio8QQONMcPzStR
+0Nnw5/8JtW/Sa7goYnE3pcABiyI6RPUVewLMrrKw2rJ91sTEgXrEqFXngDNgAza
CqGhxMl7JoWzuHO9w4aheBHKvnxXgETEj/zzafw/9hFsLcFBv3TynCWy8egvtvH2
6d3chQmIHwJ/h5R7z+qYbXTFmIEoJrr5rpK2hPqrEAUEqAXV//rX2f2xmYTHoBE=
=NOD2
-----END PGP SIGNATURE-----

--Apple-Mail=_D432A89D-32DF-40EC-98FC-94580FDA09E7--


From nobody Wed Jul 20 08:17:59 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D0B12D8BA for ; Wed, 20 Jul 2016 08:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 s76rshqfeLqt for ; Wed, 20 Jul 2016 08:17:53 -0700 (PDT)
Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E990612D92F for ; Wed, 20 Jul 2016 08:17:52 -0700 (PDT)
Received: from xiangliToshiba ([38.124.116.11]) by p3plsmtpa07-01.prod.phx3.secureserver.net with  id M3Hr1t0080EpkFa013HrcN; Wed, 20 Jul 2016 08:17:52 -0700
From: "Xiang Li" 
To: "'Jan Lindblad'" , "'Balazs Lengyel'" 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericss on.com> 
In-Reply-To: 
Date: Wed, 20 Jul 2016 10:17:48 -0500
Message-ID: <001c01d1e299$e057a910$a106fb30$@seguesoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01D1E26F.F78571A0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJZymiF5daVMVNixyVdFZ+alWovEgG1sCdUAhpApRcByA/8ZQG6xykDAo2e57ECYFVW7wIPkQWVAcJJSNUBwEEvwAFvpMjmAL0kHA8BWjvCZwLsdhBHArQm8LACTQjOHgLRAGm3Alxi0UGd/fCx8A==
Content-Language: en-us
Archived-At: 
Cc: 'Netconf' 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jul 2016 15:17:57 -0000

This is a multipart message in MIME format.

------=_NextPart_000_001D_01D1E26F.F78571A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Jan,

 

Are you saying that since a NP-container is merely a structure node, not
config in any way, so creating/deleting it explicitly (and repeatedly) is
equivalent to a "no-op" that will always succeed because doing so has no
effect on the server's config in any way? 

 

If the sever has the following example config:



     



 

 

If a client issues an edit-config with:

< mycontainer operation="delete">

 

The server returns "ok",

 

If then again  the client attempts:

 

< mycontainer operation="delete">

 

The server should still return  "ok"?

 

If so I think this is confusing. I think it would make more sense in the
latter case if the server returns ""data-missing" error.

 

I understand we may advise a client not do so, but since  RFC6020bis does
not forbid this, and it is also a perfectly valid , so I am
sure people will try it.

 
 
 
-Xiang
 

 

 

 

From: Jan Lindblad [mailto:janl@tail-f.com] 
Sent: Tuesday, July 19, 2016 11:10 PM
To: Balazs Lengyel 
Cc: Xiang Li ; Netconf 
Subject: Re: [Netconf] What should a server response be?

 

Balazs,

+ 1 or more like +++1000  I always fought against them.

The added value NP containers have compared to P containers is very low. 
The added complication is very high. A whole new concept of
existing/disappearing data node is introduced, with many special rules, some
of which are still not clear.

Aren't you exaggerating a little? NP containers are essential for making
YANG models that resemble the existing CLI structures. Look at all the
models already in RFC and at all the drafts. I had a look in the IETF DRAFTS
folder, and around 20% of the objects defined were NP containers. Far less
than 1% were P containers. It seems then that modelers find NP containers
more useful than you do.

 

NP containers are actually really simple, trivial even, but of course it's
always complicated to implement something that isn't fully understood.

As I don't see a way to kill NP containers (my first wish) I agree they
should be clarified.  Currently the RFC says: 

"If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container." 

This allows deleting only when the last child node is deleted. It does not
allow deleting an NP container after an explicit create.

For some reason you're hung up about the "creation" and "deletion" of NP
containers. I maintain that NP containers can't really be created and
deleted in a deeper sense of the word. They have zero bits of information,
so a conforming implementation cannot remember their history, and they have
no value. There are no moving parts here.

 

If it makes it easier, think of NP containers as a prefix to the name of all
the objects inside the container.

Your table does not directly answer some key questions for me:

Q1) Is it allowed to create it explicitly? Yes/No?

NP containers cannot be created, not in the sense that you can ask about
their created/not-created state later, anyway. They are mentioned in
edit-config operations, since there is no way to refer to objects inside the
containers without mentioning the container name. The NP container itself
isn't an object that has an existence property in itself, so asking whether
it can be created is moot.

Q2) Is it allowed to create it, then create it again? For a P container this
would result in a create-failed. For NP, allowed or no?

You can include an NP container in an edit-config create call as many times
as you like. "Creation" of an NP container can never result in
create-failed. NP containers have zero bits of information, so we have no
memory of whether it has been previously created or not. It's completely
uninteresting.

Q3) If it is allowed to create them, will they exist and continue to exist
in the database, or can the server delete them any time?

They do not exist in the database, other than as path prefixes to the
objects inside the container. Whether empty NP containers are returned in a
get-config operation is an implementation decision, and has nothing to do
with previous "create" or "delete" calls.

Q4) Does the NP container modify the behavior of edit-config none? Should we
fail or succeed in the provided examples? Yes/No?

There were a number of examples provided. Some should fail, some succeed. In
the recent examples named by letters a-f, I think it was only example c and
f that should succeed. Refer back to that thread for details. If you had
some other example in mind, please be specific.

Q5) When are must statements that are direct substatements of an NP
container validated? Following your logic IMHO such must statements MUST NOT
be allowed in YANG at all.  If an NP container has no meaning why do we
connect checks to them?

The must statement(s) in an NP container must be validated for each parent
node that the container exists in, e.g. for each list instance if the NP
container sits in a list. The same applies for P containers, once they are
created.

I propose to write an errata about this immediately after the YANG 1.1 RFC
comes out.

What do you propose to say in the errata?

 

/jan

 

(f) should be accepted without an error IMO.  


Ok. If f) is accepted then it indicates the server chooses to delete an
empty container
or it basically ignore the operation to create only a NP container node.

 

I agree with this.

 

I also agree that RFC 6020 could spell this out in a more direct way.
Currently the description of NP and P containers does not contain a table
with the properties of each, but instead enumerates how P containers differ
from NP containers in plain english. In order to build a such a table, I've
collected quotes on each type here:

 

P-container qoutes:

- "presence in the configuration has an explicit meaning"

- "presence of the container itself is configuration data"

- "representing a single bit of configuration data"

- "These containers are explicitly created and deleted"

- "The "presence" statement assigns a meaning to the presence of a container
in the data tree"

 

NP-container qoutes:

- "exist only for organizing the hierarchy of data nodes"

- "container has no meaning of its own, existing only to contain child
nodes"

- "the container is used to give some structure to the data, and it carries
no meaning by itself"

- "MAY choose not to send a container element if the container node does not
have the "presence" statement and no child nodes exist"

- "a client ... must be prepared to handle the case that a container node
without a "presence" statement is not present"

 

Based on the above quotes, I believe this to be a fair description of the P
and NP container differences in a tabular form:

 

                                  | P-container | NP-container |

----------------------------------+-------------+--------------+

Organizing the hierarchy          |      Y      |       Y      |

May have child nodes              |      Y      |       Y      |

Existence has meaning             |      Y      |       N      |

Is configuration data             |      Y      |       N      |

Information content               |    1 bit    |    0 bits    |

Explicitly created and deleted    |      Y      |       N      |

Suppress when empty               |      N      |      MAY     |

----------------------------------+-------------+--------------+

 

With this background, I consider it clear that "creation" and "deletion" of
P-containers has no effect on the configuration. In fact, a conforming
implementation cannot even remember/know if a P-container has been created
or not since it has zero bits of information. P-containers aren't really
configuration data, even if they may be located in the config true part of
the world.

 

If anyone sees anything wrong, unfounded or unclear with the table above, I
think it would be of high general interest that this is pointed out asap.

 

/jan

 






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





-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
  

 


------=_NextPart_000_001D_01D1E26F.F78571A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Jan,
 
Are you saying that since a NP-container is merely a structure node, =
not config in any way, so creating/deleting it explicitly (and =
repeatedly) is equivalent to a “no-op” that will always =
succeed because doing so has no effect on the server’s config in =
any way? 
 
If the sever has the following example config:
<mycontainer>
     <child  ... =
bla..bla…configs>
</mycontainer>
 
 
If a client issues an edit-config with:
< mycontainer =
operation=3D"delete">
 
The server returns “ok”,
 
If then again  the client attempts:
 
< mycontainer =
operation=3D"delete">
 
The server should still return =
 “ok”?
 
If so I think this is confusing. I think it would make more sense in =
the latter case if the server returns “"data-missing” error.
 
I understand we may advise a client not do so, but since =
 RFC6020bis does not forbid this, and it is also a perfectly valid =
<edit-config>, so I am sure people will try =
it.
 
 
 
-Xiang
 
 
 
 
From:<=
/b> =
Jan Lindblad [mailto:janl@tail-f.com] 
Sent: Tuesday, July 19, =
2016 11:10 PM
To: Balazs Lengyel =
<balazs.lengyel@ericsson.com>
Cc: Xiang Li =
<xiangli@seguesoft.com>; Netconf =
<netconf@ietf.org>
Subject: Re: [Netconf] What should a =
server response be?
 
Balazs,
+ 1 or more =
like +++1000  I always fought against =
them.
The added =
value NP containers have compared to P containers is very =
low. 
The added complication is very high. A whole new concept =
of existing/disappearing data node is introduced, with many special =
rules, some of which are still not =
clear.
Aren't you exaggerating a little? NP containers are =
essential for making YANG models that resemble the existing CLI =
structures. Look at all the models already in RFC and at all the drafts. =
I had a look in the IETF DRAFTS folder, and around 20% of the objects =
defined were NP containers. Far less than 1% were P containers. It seems =
then that modelers find NP containers more useful than you =
do.
 
NP containers are actually really simple, trivial =
even, but of course it's always complicated to implement something that =
isn't fully understood.
As I don't =
see a way to kill NP containers (my first wish) I agree they should be =
clarified.  Currently the RFC says: 
"If a =
container does not have a "presence" statement and the =
last
   child node is deleted, the NETCONF server MAY =
delete the container." 
This allows =
deleting only when the last child node is deleted. It does not allow =
deleting an NP container after an explicit =
create.
For some reason you're hung up about the =
"creation" and "deletion" of NP containers. I =
maintain that NP containers can't really be created and deleted in a =
deeper sense of the word. They have zero bits of information, so a =
conforming implementation cannot remember their history, and they have =
no value. There are no moving parts here.
 
If it makes it easier, think of NP containers as a =
prefix to the name of all the objects inside the =
container.
Your table =
does not directly answer some key questions for me:
Q1) Is it =
allowed to create it explicitly? =
Yes/No?
NP containers cannot be created, not in the sense that =
you can ask about their created/not-created state later, anyway. They =
are mentioned in edit-config operations, since there is no way to refer =
to objects inside the containers without mentioning the container name. =
The NP container itself isn't an object that has an existence property =
in itself, so asking whether it can be created is =
moot.
Q2) Is it =
allowed to create it, then create it again? For a P container this would =
result in a create-failed. For NP, allowed or =
no?
You =
can include an NP container in an edit-config create call as many times =
as you like. "Creation" of an NP container can never result in =
create-failed. NP containers have zero bits of information, so we have =
no memory of whether it has been previously created or not. It's =
completely uninteresting.
Q3) If it =
is allowed to create them, will they exist and continue to exist in the =
database, or can the server delete them any =
time?
They do not exist in the database, other than as path =
prefixes to the objects inside the container. Whether empty NP =
containers are returned in a get-config operation is an implementation =
decision, and has nothing to do with previous "create" or =
"delete" calls.
Q4) Does =
the NP container modify the behavior of edit-config none? Should we fail =
or succeed in the provided examples? =
Yes/No?
There were a number of examples provided. Some should =
fail, some succeed. In the recent examples named by letters a-f, I think =
it was only example c and f that should succeed. Refer back to that =
thread for details. If you had some other example in mind, please be =
specific.
Q5) When =
are must statements that are direct substatements of an NP container =
validated? Following your logic IMHO such must statements MUST NOT be =
allowed in YANG at all.  If an NP container has no meaning why do =
we connect checks to =
them?
The must statement(s) in an NP container must be =
validated for each parent node that the container exists in, e.g. for =
each list instance if the NP container sits in a list. The same applies =
for P containers, once they are created.
I propose =
to write an errata about this immediately after the YANG 1.1 RFC comes =
out.
What do you propose to say in the =
errata?
 
/jan
 
(f) should be accepted without =
an error IMO.  

Ok. If f) is accepted then it indicates the =
server chooses to delete an empty container
or it basically ignore the operation to =
create only a NP container =
node.
 
I =
agree with this.
 
I =
also agree that RFC 6020 could spell this out in a more direct way. =
Currently the description of NP and P containers does not contain a =
table with the properties of each, but instead enumerates how P =
containers differ from NP containers in plain english. In order to build =
a such a table, I've collected quotes on each type =
here:
 
P-container qoutes:
- "presence in the configuration has an explicit =
meaning"
- =
"presence of the container itself is configuration =
data"
- =
"representing a single bit of configuration =
data"
- "These =
containers are explicitly created and =
deleted"
- "The =
"presence" statement assigns a meaning to the presence of a =
container in the data tree"
 
NP-container qoutes:
- "exist only for organizing the hierarchy of =
data nodes"
- =
"container has no meaning of its own, existing only to contain =
child nodes"
- =
"the container is used to give some structure to the data, and it =
carries no meaning by itself"
- "MAY choose not to send a container element if =
the container node does not have the "presence" statement and =
no child nodes exist"
- "a client ... must be prepared to handle the =
case that a container node without a "presence" statement is =
not present"
 
Based on the above quotes, I believe this to be a fair =
description of the P and NP container differences in a tabular =
form:
 
                                  | P-container | NP-container =
|
----------------------------------+--------=
-----+--------------+
Organizing the =
hierarchy          |      Y      |       Y      |
May have child =
nodes              |      Y      |       Y      |
Existence has =
meaning             |      Y      |       N      |
Is configuration =
data             |      Y      |       N      |
Information =
content               |    1 bit    |    0 bits    |
Explicitly created =
and deleted    |      Y      |       N      |
Suppress when =
empty               |      N      |      MAY     |
----------------------------------+--------=
-----+--------------+
 
With this background, I consider it clear that =
"creation" and "deletion" of P-containers has no =
effect on the configuration. In fact, a conforming implementation cannot =
even remember/know if a P-container has been created or not since it has =
zero bits of information. P-containers aren't really configuration data, =
even if they may be located in the config true part of the =
world.
 
If anyone sees anything wrong, unfounded or unclear =
with the table above, I think it would be of high general interest that =
this is pointed out asap.
 
/jan
 



_______________________=
________________________
Netconf mailing =
list
Netconf@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/netconf


-- =

Balazs =
Lengyel           =
            =
Ericsson Hungary Ltd.
Senior =
Specialist
Mobile: =
+36-70-330-7909         &nbs=
p;    email: Balazs.Lengyel@ericsson.com 
 

------=_NextPart_000_001D_01D1E26F.F78571A0--



From nobody Thu Jul 21 00:17:44 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEC112DA86 for ; Thu, 21 Jul 2016 00:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 E1Zp4fzF3IhC for ; Thu, 21 Jul 2016 00:17:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E04712DA5A for ; Thu, 21 Jul 2016 00:17:41 -0700 (PDT)
Received: from [10.147.40.77] (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A8D31AE043F; Thu, 21 Jul 2016 09:17:40 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_268DBC1E-7AF9-44E8-9E86-D8FE15B109ED"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Jan Lindblad 
In-Reply-To: <001c01d1e299$e057a910$a106fb30$@seguesoft.com>
Date: Thu, 21 Jul 2016 09:17:39 +0200
Message-Id: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericss on.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>
To: Xiang Li 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 07:17:43 -0000

--Apple-Mail=_268DBC1E-7AF9-44E8-9E86-D8FE15B109ED
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_41B811C9-3CFD-4303-91AC-F476C594CD30"


--Apple-Mail=_41B811C9-3CFD-4303-91AC-F476C594CD30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Xiang,

> Are you saying that since a NP-container is merely a structure node, =
not config in any way, so creating/deleting it explicitly (and =
repeatedly) is equivalent to a =E2=80=9Cno-op=E2=80=9D that will always =
succeed because doing so has no effect on the server=E2=80=99s config in =
any way?

That's correct. "Creating" an object with zero bits of information is a =
no-op.

> If the sever has the following example config:
> 
>      
> 
>=20
>=20
> If a client issues an edit-config with:
> < mycontainer operation=3D"delete">
>=20
> The server returns =E2=80=9Cok=E2=80=9D,
>=20
> If then again  the client attempts:
>=20
> < mycontainer operation=3D"delete">
>=20
> The server should still return  =E2=80=9Cok=E2=80=9D?

Yes, that's correct in my opinion. It's a consequence of the NP =
container nature as defined in the current RFC6020/YANG 1.0 and bis.

> If so I think this is confusing. I think it would make more sense in =
the latter case if the server returns =E2=80=9C"data-missing=E2=80=9D =
error.

This is logical if you think of NP containers as path prefixes, and not =
as objects with information content. If you accept that an NP container =
has zero bits of information, how would the server even know whether the =
container exists or not? Not by looking in a database, for sure.

P containers have a single bit of information, so they can be created, =
and the creation event/existence remembered by the server. Not so for =
NP-containers.

> I understand we may advise a client not do so, but since  RFC6020bis =
does not forbid this, and it is also a perfectly valid , so =
I am sure people will try it.

Yes. And it works today and is harmless.

It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on =
the subject, but I believe the interpretation I and others have of NP =
container behavior in RFC 6020 is consistent, implementable and highly =
useful.

/jan


--Apple-Mail=_41B811C9-3CFD-4303-91AC-F476C594CD30
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Xiang,

Are you saying that since a NP-container =
is merely a structure node, not config in any way, so creating/deleting =
it explicitly (and repeatedly) is equivalent to a =E2=80=9Cno-op=E2=80=9D =
that will always succeed because doing so has no effect on the =
server=E2=80=99s config in any way? 

That's correct. "Creating" an =
object with zero bits of information is a no-op.

If =
the sever has the following example config:
<mycontainer>
     <child =
 ... bla..bla=E2=80=A6configs>
</mycontainer>
 
 
If a client issues an =
edit-config with:
< mycontainer operation=3D"delete">
 
The server returns =
=E2=80=9Cok=E2=80=9D,
 
If then again  the =
client attempts:
 
< mycontainer operation=3D"delete">
 
The server should still =
return  =E2=80=9Cok=E2=80=9D?
Yes, that's correct in my opinion. It's a =
consequence of the NP container nature as defined in the current =
RFC6020/YANG 1.0 and bis.
 
If so I think this is confusing. I think =
it would make more sense in the latter case if the server returns =
=E2=80=9C"data-missing=E2=80=9D =
error.

This =
is logical if you think of NP containers as path prefixes, and not as =
objects with information content. If you accept that an NP container has =
zero bits of information, how would the server even know whether the =
container exists or not? Not by looking in a database, for =
sure.

P containers have a single bit =
of information, so they can be created, and the creation event/existence =
remembered by the server. Not so for NP-containers.

I understand we may advise a client not do =
so, but since  RFC6020bis does not forbid this, and it is also a =
perfectly valid <edit-config>, so I am sure people will try =
it.

Yes. =
And it works today and is harmless.

It's unfortunate that the YANG 1.0 and 1.1 specs =
aren't crystal clear on the subject, but I believe the interpretation I =
and others have of NP container behavior in RFC 6020 is consistent, =
implementable and highly useful.

/jan

=

--Apple-Mail=_41B811C9-3CFD-4303-91AC-F476C594CD30--

--Apple-Mail=_268DBC1E-7AF9-44E8-9E86-D8FE15B109ED
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

iQEcBAEBCgAGBQJXkHcTAAoJEBSCnbqufIisOO8IALVTgmeVjwy6unICsdN3DgHW
DQrnK+czOVVHQwWlrlUGRJs3AoYiDLlnpc73njTiizMAsUYGNvEYYjGQ2xQyPwrI
4aLo9OxLIlxHuhHVFvIG/oJ9KQbH36vAOFpX5Bql6T49TOBLQHDaP1N/+CxT9SXD
59pR5JEW5kqhFL2JHsbcf4eNpX29pEbPsagCPZaAifHc25Q+2vrVM/0pLmSQbXpe
V/SY431Aw8evI7mDvpCYmVdIE4UwcvgWtH+mk0KHGFko4fcklrodzwvSZCHF7NDs
TIKApzxs2mxLe8jjMTxjXnXuNd/prPq9pAy3J3QyZ3m8KnsUO7RUvivGovXZGkk=
=Qqh8
-----END PGP SIGNATURE-----

--Apple-Mail=_268DBC1E-7AF9-44E8-9E86-D8FE15B109ED--


From nobody Thu Jul 21 06:56:47 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8812D1DA for ; Thu, 21 Jul 2016 06:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CRVgkjCWDS1A for ; Thu, 21 Jul 2016 06:56:43 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66D312D548 for ; Thu, 21 Jul 2016 06:56:42 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 21CEFA33C34CA; Thu, 21 Jul 2016 13:56:39 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u6LDufsT008081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2016 13:56:41 GMT
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u6LDueaA006727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jul 2016 13:56:40 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.104]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 21 Jul 2016 09:56:40 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Jan Lindblad , Xiang Li 
Thread-Topic: [Netconf] What should a server response be?
Thread-Index: AQHR3esI0j4IVR1/2kW9+f8gjxD6tKAYQ0SQgABICoD//73wYIAARsmAgAE80QWAAAaIwIAIsMc7gABuHlA=
Date: Thu, 21 Jul 2016 13:56:39 +0000
Message-ID: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <5786B8CE.3040507@seguesoft.com>        <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericss on.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CCDF1DDUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 13:56:46 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CCDF1DDUS70TWXCHMBA11z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB3aXRoIEphbuKAmXMgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGV4cGVjdGVkIGJlaGF2
aW9yIChhbmQgdGhlIHVzZWZ1bG5lc3Mgb2YgTlAgY29udGFpbmVycykuICBBIGRlbGV0ZSBvciBj
cmVhdGUgb24gYW4gTlAtY29udGFpbmVyIG5vZGUgc2hvdWxkIGFsd2F5cyBzdWNjZWVkIChwcmV2
aW91cyBvcGVyYXRpb25zIGFuZCBjdXJyZW50IHN0YXRlIG9mIHRoZSBkYXRhc3RvcmUgaXMgaXJy
ZWxldmFudCkuDQoNClRoZSBOUC1jb250YWluZXIgaXNu4oCZdCBhY3R1YWxseSBkZWxldGVkIG9y
IGNyZWF0ZWQgaW4gdGhlIGRhdGFzdG9yZSBJTU8gYnV0IHRoZSBlZGl0LWNvbmZpZyBzaG91bGQg
cmV0dXJuIDxvaz4uDQoNClN1YnNlcXVlbnQgPGdldC1jb25maWc+IG9yIDxnZXQ+IHJlc3BvbnNl
cyBtYXkgc3VwcHJlc3MgTlAtY29udGFpbmVycyBpZiB0aGV5IGFyZSBlbXB0eSAoSSBkb27igJl0
IGxvdmUgdGhlIHRlcm0g4oCYZGVsZXRl4oCZIGluICDigJxNQVkgZGVsZXRl4oCdIGluIHRoZSBS
RkMuICBJdCBpcyBtb3JlIG9mIGEgc3VwcHJlc3Npb24gSU1PKS4NCg0KRnJvbTogTmV0Y29uZiBb
bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbiBMaW5kYmxh
ZA0KU2VudDogVGh1cnNkYXksIEp1bHkgMjEsIDIwMTYgMzoxOA0KVG86IFhpYW5nIExpDQpDYzog
TmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBXaGF0IHNob3VsZCBhIHNlcnZlciByZXNw
b25zZSBiZT8NCg0KWGlhbmcsDQoNCkFyZSB5b3Ugc2F5aW5nIHRoYXQgc2luY2UgYSBOUC1jb250
YWluZXIgaXMgbWVyZWx5IGEgc3RydWN0dXJlIG5vZGUsIG5vdCBjb25maWcgaW4gYW55IHdheSwg
c28gY3JlYXRpbmcvZGVsZXRpbmcgaXQgZXhwbGljaXRseSAoYW5kIHJlcGVhdGVkbHkpIGlzIGVx
dWl2YWxlbnQgdG8gYSDigJxuby1vcOKAnSB0aGF0IHdpbGwgYWx3YXlzIHN1Y2NlZWQgYmVjYXVz
ZSBkb2luZyBzbyBoYXMgbm8gZWZmZWN0IG9uIHRoZSBzZXJ2ZXLigJlzIGNvbmZpZyBpbiBhbnkg
d2F5Pw0KDQpUaGF0J3MgY29ycmVjdC4gIkNyZWF0aW5nIiBhbiBvYmplY3Qgd2l0aCB6ZXJvIGJp
dHMgb2YgaW5mb3JtYXRpb24gaXMgYSBuby1vcC4NCg0KSWYgdGhlIHNldmVyIGhhcyB0aGUgZm9s
bG93aW5nIGV4YW1wbGUgY29uZmlnOg0KPG15Y29udGFpbmVyPg0KICAgICA8Y2hpbGQgIC4uLiBi
bGEuLmJsYeKApmNvbmZpZ3M+DQo8L215Y29udGFpbmVyPg0KDQoNCklmIGEgY2xpZW50IGlzc3Vl
cyBhbiBlZGl0LWNvbmZpZyB3aXRoOg0KPCBteWNvbnRhaW5lciBvcGVyYXRpb249ImRlbGV0ZSI+
DQoNClRoZSBzZXJ2ZXIgcmV0dXJucyDigJxva+KAnSwNCg0KSWYgdGhlbiBhZ2FpbiAgdGhlIGNs
aWVudCBhdHRlbXB0czoNCg0KPCBteWNvbnRhaW5lciBvcGVyYXRpb249ImRlbGV0ZSI+DQoNClRo
ZSBzZXJ2ZXIgc2hvdWxkIHN0aWxsIHJldHVybiAg4oCcb2vigJ0/DQoNClllcywgdGhhdCdzIGNv
cnJlY3QgaW4gbXkgb3Bpbmlvbi4gSXQncyBhIGNvbnNlcXVlbmNlIG9mIHRoZSBOUCBjb250YWlu
ZXIgbmF0dXJlIGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQgUkZDNjAyMC9ZQU5HIDEuMCBhbmQg
YmlzLg0KDQpJZiBzbyBJIHRoaW5rIHRoaXMgaXMgY29uZnVzaW5nLiBJIHRoaW5rIGl0IHdvdWxk
IG1ha2UgbW9yZSBzZW5zZSBpbiB0aGUgbGF0dGVyIGNhc2UgaWYgdGhlIHNlcnZlciByZXR1cm5z
IOKAnCJkYXRhLW1pc3NpbmfigJ0gZXJyb3IuDQoNClRoaXMgaXMgbG9naWNhbCBpZiB5b3UgdGhp
bmsgb2YgTlAgY29udGFpbmVycyBhcyBwYXRoIHByZWZpeGVzLCBhbmQgbm90IGFzIG9iamVjdHMg
d2l0aCBpbmZvcm1hdGlvbiBjb250ZW50LiBJZiB5b3UgYWNjZXB0IHRoYXQgYW4gTlAgY29udGFp
bmVyIGhhcyB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24sIGhvdyB3b3VsZCB0aGUgc2VydmVyIGV2
ZW4ga25vdyB3aGV0aGVyIHRoZSBjb250YWluZXIgZXhpc3RzIG9yIG5vdD8gTm90IGJ5IGxvb2tp
bmcgaW4gYSBkYXRhYmFzZSwgZm9yIHN1cmUuDQoNClAgY29udGFpbmVycyBoYXZlIGEgc2luZ2xl
IGJpdCBvZiBpbmZvcm1hdGlvbiwgc28gdGhleSBjYW4gYmUgY3JlYXRlZCwgYW5kIHRoZSBjcmVh
dGlvbiBldmVudC9leGlzdGVuY2UgcmVtZW1iZXJlZCBieSB0aGUgc2VydmVyLiBOb3Qgc28gZm9y
IE5QLWNvbnRhaW5lcnMuDQoNCkkgdW5kZXJzdGFuZCB3ZSBtYXkgYWR2aXNlIGEgY2xpZW50IG5v
dCBkbyBzbywgYnV0IHNpbmNlICBSRkM2MDIwYmlzIGRvZXMgbm90IGZvcmJpZCB0aGlzLCBhbmQg
aXQgaXMgYWxzbyBhIHBlcmZlY3RseSB2YWxpZCA8ZWRpdC1jb25maWc+LCBzbyBJIGFtIHN1cmUg
cGVvcGxlIHdpbGwgdHJ5IGl0Lg0KDQpZZXMuIEFuZCBpdCB3b3JrcyB0b2RheSBhbmQgaXMgaGFy
bWxlc3MuDQoNCkl0J3MgdW5mb3J0dW5hdGUgdGhhdCB0aGUgWUFORyAxLjAgYW5kIDEuMSBzcGVj
cyBhcmVuJ3QgY3J5c3RhbCBjbGVhciBvbiB0aGUgc3ViamVjdCwgYnV0IEkgYmVsaWV2ZSB0aGUg
aW50ZXJwcmV0YXRpb24gSSBhbmQgb3RoZXJzIGhhdmUgb2YgTlAgY29udGFpbmVyIGJlaGF2aW9y
IGluIFJGQyA2MDIwIGlzIGNvbnNpc3RlbnQsIGltcGxlbWVudGFibGUgYW5kIGhpZ2hseSB1c2Vm
dWwuDQoNCi9qYW4NCg0K

--_000_A125E53CE190A749957C19483DC79F9F5CCDF1DDUS70TWXCHMBA11z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1z
cGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z
aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
IGFncmVlIHdpdGggSmFu4oCZcyBpbnRlcnByZXRhdGlvbiBvZiB0aGUgZXhwZWN0ZWQgYmVoYXZp
b3IgKGFuZCB0aGUgdXNlZnVsbmVzcyBvZiBOUCBjb250YWluZXJzKS4mbmJzcDsgQSBkZWxldGUg
b3IgY3JlYXRlIG9uIGFuIE5QLWNvbnRhaW5lciBub2RlIHNob3VsZCBhbHdheXMNCiBzdWNjZWVk
IChwcmV2aW91cyBvcGVyYXRpb25zIGFuZCBjdXJyZW50IHN0YXRlIG9mIHRoZSBkYXRhc3RvcmUg
aXMgaXJyZWxldmFudCkuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIE5QLWNvbnRhaW5lciBpc27igJl0
IGFjdHVhbGx5IGRlbGV0ZWQgb3IgY3JlYXRlZCBpbiB0aGUgZGF0YXN0b3JlIElNTyBidXQgdGhl
IGVkaXQtY29uZmlnIHNob3VsZCByZXR1cm4gJmx0O29rJmd0Oy4mbmJzcDsNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
U3Vic2VxdWVudCAmbHQ7Z2V0LWNvbmZpZyZndDsgb3IgJmx0O2dldCZndDsgcmVzcG9uc2VzIG1h
eSBzdXBwcmVzcyBOUC1jb250YWluZXJzIGlmIHRoZXkgYXJlIGVtcHR5IChJIGRvbuKAmXQgbG92
ZSB0aGUgdGVybSDigJhkZWxldGXigJkgaW4gJm5ic3A74oCcTUFZIGRlbGV0ZeKAnSBpbiB0aGUg
UkZDLiZuYnNwOyBJdCBpcw0KIG1vcmUgb2YgYSBzdXBwcmVzc2lvbiBJTU8pLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPkphbiBMaW5kYmxhZDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg
SnVseSAyMSwgMjAxNiAzOjE4PGJyPg0KPGI+VG86PC9iPiBYaWFuZyBMaTxicj4NCjxiPkNjOjwv
Yj4gTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFdoYXQgc2hvdWxk
IGEgc2VydmVyIHJlc3BvbnNlIGJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlhpYW5nLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QXJlIHlvdSBzYXlpbmcgdGhhdCBzaW5jZSBhIE5QLWNvbnRhaW5l
ciBpcyBtZXJlbHkgYSBzdHJ1Y3R1cmUgbm9kZSwgbm90IGNvbmZpZyBpbiBhbnkgd2F5LCBzbyBj
cmVhdGluZy9kZWxldGluZyBpdCBleHBsaWNpdGx5IChhbmQgcmVwZWF0ZWRseSkgaXMgZXF1aXZh
bGVudA0KIHRvIGEg4oCcbm8tb3DigJ0gdGhhdCB3aWxsIGFsd2F5cyBzdWNjZWVkIGJlY2F1c2Ug
ZG9pbmcgc28gaGFzIG5vIGVmZmVjdCBvbiB0aGUgc2VydmVy4oCZcyBjb25maWcgaW4gYW55IHdh
eT88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBjb3JyZWN0LiAmcXVvdDtDcmVhdGluZyZxdW90
OyBhbiBvYmplY3Qgd2l0aCB6ZXJvIGJpdHMgb2YgaW5mb3JtYXRpb24gaXMgYSBuby1vcC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIHNldmVyIGhhcyB0
aGUgZm9sbG93aW5nIGV4YW1wbGUgY29uZmlnOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbHQ7bXljb250YWluZXImZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbHQ7Y2hp
bGQgJm5ic3A7Li4uIGJsYS4uYmxh4oCmY29uZmlncyZndDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9teWNvbnRhaW5lciZndDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBhIGNsaWVudCBpc3N1ZXMgYW4gZWRpdC1jb25maWcg
d2l0aDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jmx0Ozwvc3Bhbj48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+bXljb250YWluZXI8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm9wZXJhdGlvbj0mcXVvdDtkZWxldGUm
cXVvdDsmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgc2Vy
dmVyIHJldHVybnMg4oCcb2vigJ0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5JZiB0aGVuIGFnYWluICZuYnNwO3RoZSBjbGllbnQgYXR0ZW1wdHM6PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90
O3NlcmlmJnF1b3Q7Ij4mbHQ7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5teWNv
bnRhaW5lcjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz
ZXJpZiZxdW90OyI+b3BlcmF0aW9uPSZxdW90O2RlbGV0ZSZxdW90OyZndDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBzZXJ2ZXIgc2hvdWxkIHN0aWxsIHJldHVy
biAmbmJzcDvigJxva+KAnT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhhdCdzIGNvcnJlY3Qg
aW4gbXkgb3Bpbmlvbi4gSXQncyBhIGNvbnNlcXVlbmNlIG9mIHRoZSBOUCBjb250YWluZXIgbmF0
dXJlIGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQgUkZDNjAyMC9ZQU5HIDEuMCBhbmQgYmlzLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHNvIEkgdGhpbmsgdGhpcyBpcyBj
b25mdXNpbmcuIEkgdGhpbmsgaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIGluIHRoZSBsYXR0ZXIg
Y2FzZSBpZiB0aGUgc2VydmVyIHJldHVybnMg4oCcPC9zcGFuPiZxdW90O2RhdGEtbWlzc2luZ+KA
nSBlcnJvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBsb2dpY2FsIGlmIHlvdSB0aGluayBvZiBOUCBj
b250YWluZXJzIGFzIHBhdGggcHJlZml4ZXMsIGFuZCBub3QgYXMgb2JqZWN0cyB3aXRoIGluZm9y
bWF0aW9uIGNvbnRlbnQuIElmIHlvdSBhY2NlcHQgdGhhdCBhbiBOUCBjb250YWluZXIgaGFzIHpl
cm8gYml0cyBvZiBpbmZvcm1hdGlvbiwgaG93IHdvdWxkIHRoZSBzZXJ2ZXIgZXZlbiBrbm93IHdo
ZXRoZXIgdGhlIGNvbnRhaW5lciBleGlzdHMgb3INCiBub3Q/IE5vdCBieSBsb29raW5nIGluIGEg
ZGF0YWJhc2UsIGZvciBzdXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5QIGNvbnRhaW5lcnMgaGF2ZSBhIHNpbmdsZSBiaXQgb2YgaW5mb3Jt
YXRpb24sIHNvIHRoZXkgY2FuIGJlIGNyZWF0ZWQsIGFuZCB0aGUgY3JlYXRpb24gZXZlbnQvZXhp
c3RlbmNlIHJlbWVtYmVyZWQgYnkgdGhlIHNlcnZlci4gTm90IHNvIGZvciBOUC1jb250YWluZXJz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHVuZGVyc3RhbmQg
d2UgbWF5IGFkdmlzZSBhIGNsaWVudCBub3QgZG8gc28sIGJ1dCBzaW5jZSAmbmJzcDtSRkM2MDIw
YmlzIGRvZXMgbm90IGZvcmJpZCB0aGlzLCBhbmQgaXQgaXMgYWxzbyBhIHBlcmZlY3RseSB2YWxp
ZCAmbHQ7ZWRpdC1jb25maWcmZ3Q7LCBzbyBJIGFtIHN1cmUgcGVvcGxlDQogd2lsbCB0cnkgaXQu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIEFuZCBpdCB3b3JrcyB0b2RheSBhbmQgaXMgaGFybWxl
c3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pkl0J3MgdW5mb3J0dW5hdGUgdGhhdCB0aGUgWUFORyAxLjAgYW5kIDEuMSBzcGVjcyBhcmVuJ3Qg
Y3J5c3RhbCBjbGVhciBvbiB0aGUgc3ViamVjdCwgYnV0IEkgYmVsaWV2ZSB0aGUgaW50ZXJwcmV0
YXRpb24gSSBhbmQgb3RoZXJzIGhhdmUgb2YgTlAgY29udGFpbmVyIGJlaGF2aW9yIGluIFJGQyA2
MDIwIGlzIGNvbnNpc3RlbnQsIGltcGxlbWVudGFibGUgYW5kIGhpZ2hseSB1c2VmdWwuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9qYW48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_A125E53CE190A749957C19483DC79F9F5CCDF1DDUS70TWXCHMBA11z_--


From nobody Thu Jul 21 07:38:56 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18C012D667 for ; Thu, 21 Jul 2016 07:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUskAgDMpj85 for ; Thu, 21 Jul 2016 07:38:50 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20104.outbound.protection.outlook.com [40.107.2.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8218E12D51A for ; Thu, 21 Jul 2016 07:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JoIFTL52Q881EvTu3hH4rl8A2HO2W7/KUnk/8IhEDek=; b=F5GS9uq0WqNW57qjmnZ93ig8ZWzkwEVfLbjR8j1apj1yIrjZoVz3TfoRMPL4kV+Fd1E3xpO6TQ+dnW5Fs07MowgHJK/9plt40gVl1gnWgpkA5fcebGF6qVyNh2be30S+eZYHAYp1yb5nKqju35wW9pyyRe0CdT4VieTZ1rlXOGw=
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2860.eurprd07.prod.outlook.com (10.168.91.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Thu, 21 Jul 2016 14:38:46 +0000
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 14:38:46 +0000
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: Benoit Claise , Netconf 
Thread-Topic: NETCONF WG Session Summary and AIs from IETF #96
Thread-Index: AdHjXZVfsF5FWEfiQbu6LKyEzhI5HQ==
Date: Thu, 21 Jul 2016 14:38:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; 
x-originating-ip: [62.159.77.186]
x-ms-office365-filtering-correlation-id: 2c3ff026-8f5a-41f2-4045-08d3b174b8a4
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2860; 6:0EFoQko96CiSRXPeh8ku10igDdLxQ0LAA/Mxzw+rY8UBljBaFuh2yeB6RqHabwnojXk4vJ8nE8VlULn4e2tHNWDLv+R0lcgg3VSVMp3lbbc2SOQ2BqAh3v5sz0qCVMtZ3d+E3B/QC0ceg3cE0S4ADZAr2FNYGsMxre0lzsX3+W0EL2/y5H3LkXE1sJruohfXu1EGvNOGoRYFviIoU0bVGQDf87W1xtQEECuJm9xDSz5I4z+l6n8VbUPe97Z2tmG8L/1oUT14nYlMYiEs3GD7cQArGuqLii3UXIUc0HOhN8OTWGBtg2XVr0W9QFt4YGWCKaWu7inexiB0QWV4qKpY9g==; 5:XDRbKj+kkT2K7fi0N5SBj7e+EJbxu0v9aDo2zs5HQK68uDDOydWITRJOSF8SemCBo7JTEEFPBysf41vgl8VvWz0HxYCYe+gDmMzIThhM2zHM9V6QouUyv9DGLS+X/J4ehN4kSDQGcodWVhLno6yo5A==; 24:6WM1VsKqFRpwpTtfSxBMyf/Fo2DKOTsX7IBxHXr8XCL2PUx4D2PvPxPTbv+SvMOrX1/u2jYiWtj+aj72rjy/odHAAIHk5bX7vr2TCSMOY1I=; 7:21FdMio9FF1YY4XadfSgbRW8lPJkYvg51idXTiLVc7Ehpu9M4xq9SwYuOiTHntY7KmZwxh/5WTLmkfCF3aS3iTFIt3i4veZkeh9xiQNZfC1F1W0UkXslpHBtS5Ne5a3yW9kADOab3yHvzHO2FQfRMPj1z9Roaq9yopQfoUEJhgEnZ7fMvy86uknEztms+tT/b1wGxjPbg7z0xfVk8p4uGoXm1hLOYL0rm9L7PsLNZKTGo09TBXSz4i2je8Qvh+gA
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2860;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);  SRVR:HE1PR0701MB2860; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2860; 
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(279900001)(189002)(199003)(2900100001)(97736004)(5001770100001)(87936001)(9686002)(50986999)(107886002)(86362001)(229853001)(189998001)(8936002)(19625305001)(54356999)(11100500001)(19609705001)(3660700001)(15975445007)(19300405004)(77096005)(105586002)(122556002)(2906002)(92566002)(19580395003)(76576001)(561944003)(19625215002)(7846002)(33656002)(5002640100001)(68736007)(7906003)(7696003)(5003600100003)(7736002)(10400500002)(74316002)(8676002)(101416001)(3280700002)(586003)(102836003)(3846002)(6116002)(790700001)(19617315012)(81166006)(106356001)(81156014)(66066001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2860; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2859D3E5221BFA50F460F16F91090HE1PR0701MB2859_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 14:38:45.8994 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2860
Archived-At: 
Subject: [Netconf] NETCONF WG Session Summary and AIs from IETF #96
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 14:38:55 -0000

--_000_HE1PR0701MB2859D3E5221BFA50F460F16F91090HE1PR0701MB2859_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBCZW5vaXQsIE5FVENPTkYgV0csDQoNCmJlbG93IGlzIHRoZSBORVRDT05GIFdHIHNlc3Np
b24gc3VtbWFyeSBhbmQgQUlzIGZyb20gSUVURiAjOTYuDQoNCj0+IFRoaXMgbWFpbCBpcyBhdCB0
aGUgc2FtZSB0aW1lIHRvIHZlcmlmeS92YWxpZGF0ZSB0aGUgZGlzY3Vzc2lvbiByZXN1bHQgYW5k
IGRlY2lzaW9ucyBmcm9tIHRoZSBJRVRGIDk2IE5FVENPTkYgc2Vzc2lvbi4NCj0+IElmIHRoZXJl
IGlzIG5vIHN0cm9uZyBvYmplY3Rpb24gd2Ugd2lsbCBpbXBsZW1lbnQgYXMgZGlzY3Vzc2VkLg0K
DQpUaGUgTkVUQ09ORiBzZXNzaW9uIHRvb2sgcGxhY2Ugb24gTW9uZGF5LCBKdWx5IDE4LCAyMDE2
LCBmcm9tIDEwOjAwIOKAkyAxMjozMCBDRVQgQmVybGluLCBHZXJtYW55Lg0KDQotIFdlIGhhZCBh
cHByb3guIDEyMCsgcGFydGljaXBhbnRzIGluIHRoZSAyLjUgaG91ciBORVRDT05GIHNlc3Npb24s
DQotIFdlIHJldmlld2VkIHRoZSBzdGF0dXMgb2YgdGhlIFdHLA0KLSBXZSBoYWQgYSBkaXNjdXNz
aW9uIG9uIGNoYXJ0ZXJlZCBkb2N1bWVudHMuDQoNClRoZSByb3VnaCBub3RlcyBmcm9tIHRoZSBF
dGhlcnBhZCBhcmUgYXZhaWxhYmxlIGF0Og0KaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3Jn
OjkwMDAvcC9ub3Rlcy1pZXRmLTk2LW5ldGNvbmY/dXNlTW9ub3NwYWNlRm9udD10cnVlDQoNCg0K
Q2hhcnRlcmVkIGl0ZW1zOg0KICAgICAgMS4gUmVwb3J0IGZyb20gZG9jdW1lbnRzIGFmdGVyIFdH
TEM6IFJlc3Rjb25mLCBZYW5nLXBhdGNoIC0gQS4gQmllcm1hbiAoMTUgbWluLikNCkFuZHkgd2ls
bCBwcm92aWRlIGFuIHVwZGF0ZSBmb3IgUkVTVENPTkYgYW5kIFlBTkcgUGF0Y2ggYnkgbmV4dCB3
ZWVrLg0KDQogICAgICAyLiBTdWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0
ZXMgLSBFcmljIFZvaXQgKDE1IG1pbikNCiAgICAgIDMuIFN1YnNjcmlwdGlvbnMgZm9yIEV2ZW50
IE5vdGlmaWNhdGlvbnMgKFJGQyA1Mjc3YmlzKSAtIEVyaWMgVm9pdCAoMTUgbWluKQ0KICAgICAg
NC4gTkVUQ09ORiBUcmFuc3BvcnQgZm9yIEV2ZW50IE5vdGlmaWNhdGlvbnMgLSBFcmljIFZvaXQg
KDEwIG1pbikNCiAgICAgIDUuIFJFU1RDT05GICYgSFRUUCBUcmFuc3BvcnQgZm9yIEV2ZW50IE5v
dGlmaWNhdGlvbnMgLSBFcmljIFZvaXQgKDUgbWluKQ0K4oCcWUFORyBQdXNo4oCdIGRyYWZ0cyB3
ZXJlIGRpc2N1c3NlZC4gVGhlIFdHIGFncmVlZCB0byBhZG9wdCB0aGUgdGhyZWUgZHJhZnRzIDUy
NzdiaXMsIE5FVENPTkYgVHJhbnNwb3J0IGFuZCBSRVNUQ09ORiAmIEhUVFAgVHJhbnNwb3J0Lg0K
VGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnRzIHdpbGwgYmUgYWNjZXB0ZWQgYXMgZHJhZnQt
aWV0Zi4NCg0KICAgICAgNi4gU3lzdGVtIEtleWNoYWluIE1vZGVsIC0gSy4gV2F0c2VuDQogICAg
ICA3LiBTU0ggQ2xpZW50IFNlcnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KICAgICAgOC4gVExTIENs
aWVudCBTZXJ2ZXIgTW9kZWwgLSBLLiBXYXRzZW4NCiAgICAgIDkuIE5FVENPTkYgQ2xpZW50IFNl
cnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KICAgICAxMC4gUkVTVENPTkYgQ2xpZW50IFNlcnZlciBN
b2RlbCAtIEsuIFdhdHNlbg0KICAgICAxMS4gWmVybyBUb3VjaCBQcm92aXNpb25pbmcgZm9yIE5F
VENPTkYgQ2FsbCBIb21lIChaZXJvVG91Y2gpIC0gSy4gV2F0c2VuDQpJc3N1ZSBkaXNjdXNzaW9u
LiBJc3N1ZXMgd2lsbCBiZSBhZGRyZXNzZWQgYW5kIGRyYWZ0cyB3aWxsIGJlIHVwZGF0ZWQgYXMg
ZGlzY3Vzc2VkLg0KQ2xpZW50IG1vZGVscyB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0aGUgbmV4dCB2
ZXJzaW9uLg0KDQpOb24tQ2hhcnRlcmVkIGl0ZW1zOg0KICAgICAgMS4gSTJSUyBzdHJhd21hbiBw
cm9wb3NhbCAtIFMuIEhhcmVzDQpTdWUgcHJlc2VudGVkIHRoZSBJMlJTIHJlcXVpcmVtZW50cyBk
b2N1bWVudGVkIGluIGVwaGVtZXJhbCBzdGF0ZSBkcmFmdC4gVGhlcmUgd2FzIG5vIGZ1cnRoZXIg
Y29tbWVudHMuDQpUaGUgY2hhaXJzIGFza2VkIHRoZSBhdHRlbmRlZXMgdG8gY29tbWVudCBhbmQg
ZGlzY3VzcyBpZiB0aGV5IHNlZSBhbiBpc3N1ZS4gT3RoZXJ3aXNlIHRoZXkgd2lsbCBhcmUgc2Vl
biBhcyBhY2NlcHRlZC4NClN1ZSBhZ3JlZWQgdG8gcHJvdmlkZSBhbiBvdmVydmlldyBvbiB3aGlj
aCByZXF1aXJlbWVudHMgYXJlIGFkZHJlc3NlZCBpbiB3aGljaCBkcmFmdCBhbmQgd2hlcmUgYW4g
YWN0aW9uIGlzIG5lY2Vzc2FyeS4NCg0KICAgICAgMi4gUmVmaW5lZCBZQU5HIGRhdGFzdG9yZXMg
d2l0aCBNZXRhLWRhdGENClRoZSBkYXRhc3RvcmUgY29uY2VwdHVhbCBkaXNjdXNzaW9uIGlzIGNv
bnRpbnVpbmcgaW4gTkVUTU9EIFdHLg0KSXQgaGFzIGJlZW4gcHJvcG9zZWQgdGhhdCB0aGUgYXJj
aGl0ZWN0dXJhbCBkaXNjdXNzaW9uIHNob3VsZCBiZSBjb250aW51ZWQgaW4gTkVUTU9EIFdHIGFu
ZA0KdGhlIHByb3RvY29sIHBhcnQgYXMgd2VsbCBhcyB0aGUgbmVjZXNzYXJ5IGNoYW5nZXMgdG8g
dGhlIGRhdGFzdG9yZSBkZWZpbml0aW9uIHRvIE5FVENPTkYgUkZDIHNob3VsZCBiZSBkb25lIGlu
IE5FVENPTkYgV0cuDQoNCk1laG1ldCAmIE1haGVzaA0KDQo=

--_000_HE1PR0701MB2859D3E5221BFA50F460F16F91090HE1PR0701MB2859_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5lbWFp
bHF1b3RlLCBsaS5lbWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTpl
bWFpbHF1b3RlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz
cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMENDO30NCnNwYW4uRW1haWxTdHls
ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOiMwMDAwQ0M7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6IzAwMDA5OTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7
DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjojMDAwMENDOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h
bDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOiMwMDAwOTk7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y
bWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzAwMDBDQzsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu
b3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyNA0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMDk5Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250
LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w
cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPkRlYXIgQmVub2l0LCBORVRDT05G
IFdHLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5iZWxvdyBp
cyB0aGUgTkVUQ09ORiBXRyBzZXNzaW9uIHN1bW1hcnkgYW5kIEFJcyBmcm9tIElFVEYgIzk2Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PSZndDsgVGhpcyBtYWls
IGlzIGF0IHRoZSBzYW1lIHRpbWUgdG8gdmVyaWZ5L3ZhbGlkYXRlIHRoZSBkaXNjdXNzaW9uIHJl
c3VsdCBhbmQgZGVjaXNpb25zIGZyb20gdGhlIElFVEYgOTYgTkVUQ09ORiBzZXNzaW9uLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAwMDk5Ij49Jmd0OyBJZiB0aGVyZSBpcyBubyBzdHJvbmcgb2JqZWN0aW9uIHdlIHdp
bGwgaW1wbGVtZW50IGFzIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDAwOTkiPlRoZSBORVRDT05GIHNlc3Npb24gdG9vayBwbGFjZSBvbiBNb25kYXksIEp1
bHkgMTgsIDIwMTYsIGZyb20gMTA6MDAg4oCTIDEyOjMwIENFVCBCZXJsaW4sIEdlcm1hbnkuDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMDA5OSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPi0gV2UgaGFkIGFwcHJv
eC4gMTIwJiM0MzsgcGFydGljaXBhbnRzIGluIHRoZSAyLjUgaG91ciBORVRDT05GIHNlc3Npb24s
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDAwOTkiPi0gV2UgcmV2aWV3ZWQgdGhlIHN0YXR1cyBvZiB0aGUgV0csPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDAwOTkiPi0gV2UgaGFkIGEgZGlzY3Vzc2lvbiBvbiBjaGFydGVyZWQgZG9jdW1l
bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAwMDk5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+VGhlIHJvdWdo
IG5vdGVzIGZyb20gdGhlIEV0aGVycGFkIGFyZSBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAw
OTkiPjxhIGhyZWY9Imh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMt
aWV0Zi05Ni1uZXRjb25mP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1ZSI+aHR0cDovL2V0aGVycGFkLnRv
b2xzLmlldGYub3JnOjkwMDAvcC9ub3Rlcy1pZXRmLTk2LW5ldGNvbmY/dXNlTW9ub3NwYWNlRm9u
dD10cnVlPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Q2hhcnRlcmVkIGl0ZW1zOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4gUmVwb3J0IGZyb20gZG9jdW1lbnRz
IGFmdGVyIFdHTEM6IFJlc3Rjb25mLCBZYW5nLXBhdGNoIC0gQS4gQmllcm1hbiAoMTUgbWluLik8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMDA5OSI+QW5keSB3aWxsIHByb3ZpZGUgYW4gdXBkYXRlIGZvciBSRVNUQ09O
RiBhbmQgWUFORyBQYXRjaCBieSBuZXh0IHdlZWsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAwMDk5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4gU3Vic2Ny
aWJpbmcgdG8gWUFORyBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzIC0gRXJpYyBWb2l0ICgxNSBtaW4p
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLiBTdWJz
Y3JpcHRpb25zIGZvciBFdmVudCBOb3RpZmljYXRpb25zIChSRkMgNTI3N2JpcykgLSBFcmljIFZv
aXQgKDE1IG1pbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDQuIE5FVENPTkYgVHJhbnNwb3J0IGZvciBFdmVudCBOb3RpZmljYXRpb25zIC0gRXJpYyBW
b2l0ICgxMCBtaW4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA1LiBSRVNUQ09ORiAmYW1wOyBIVFRQIFRyYW5zcG9ydCBmb3IgRXZlbnQgTm90aWZpY2F0
aW9ucyAtIEVyaWMgVm9pdCAoNSBtaW4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPuKAnFlBTkcgUHVzaOKA
nSBkcmFmdHMgd2VyZSBkaXNjdXNzZWQuIFRoZSBXRyBhZ3JlZWQgdG8gYWRvcHQgdGhlIHRocmVl
IGRyYWZ0cyA1Mjc3YmlzLCBORVRDT05GIFRyYW5zcG9ydCBhbmQgUkVTVENPTkYgJmFtcDsgSFRU
UCBUcmFuc3BvcnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+VGhlIG5leHQgdmVyc2lvbiBvZiB0aGUg
ZHJhZnRzIHdpbGwgYmUgYWNjZXB0ZWQgYXMgZHJhZnQtaWV0Zi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2
LiBTeXN0ZW0gS2V5Y2hhaW4gTW9kZWwgLSBLLiBXYXRzZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDcuIFNTSCBDbGllbnQgU2VydmVyIE1vZGVsIC0g
Sy4gV2F0c2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA4LiBUTFMgQ2xpZW50IFNlcnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAw
OTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzkuIE5FVENPTkYgQ2xpZW50
IFNlcnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOzEwLiBSRVNUQ09ORiBDbGllbnQgU2VydmVyIE1vZGVsIC0gSy4g
V2F0c2VuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
MTEuIFplcm8gVG91Y2ggUHJvdmlzaW9uaW5nIGZvciBORVRDT05GIENhbGwgSG9tZSAoWmVyb1Rv
dWNoKSAtIEsuIFdhdHNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5Jc3N1ZSBkaXNjdXNzaW9uLiBJc3N1
ZXMgd2lsbCBiZSBhZGRyZXNzZWQgYW5kIGRyYWZ0cyB3aWxsIGJlIHVwZGF0ZWQgYXMgZGlzY3Vz
c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5DbGllbnQgbW9kZWxzIHdpbGwgYmUgYWRkcmVzc2VkIGlu
IHRoZSBuZXh0IHZlcnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw
MDk5Ij5Ob24tQ2hhcnRlcmVkIGl0ZW1zOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEu
IEkyUlMgc3RyYXdtYW4gcHJvcG9zYWwgLSBTLiBIYXJlcw0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPlN1
ZSBwcmVzZW50ZWQgdGhlIEkyUlMgcmVxdWlyZW1lbnRzIGRvY3VtZW50ZWQgaW4gZXBoZW1lcmFs
IHN0YXRlIGRyYWZ0LiBUaGVyZSB3YXMgbm8gZnVydGhlciBjb21tZW50cy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MDA5OSI+VGhlIGNoYWlycyBhc2tlZCB0aGUgYXR0ZW5kZWVzIHRvIGNvbW1lbnQgYW5kIGRpc2N1
c3MgaWYgdGhleSBzZWUgYW4gaXNzdWUuIE90aGVyd2lzZSB0aGV5IHdpbGwgYXJlIHNlZW4gYXMg
YWNjZXB0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPlN1ZSBhZ3JlZWQgdG8gcHJvdmlkZSBhbiBvdmVy
dmlldyBvbiB3aGljaCByZXF1aXJlbWVudHMgYXJlIGFkZHJlc3NlZCBpbiB3aGljaCBkcmFmdCBh
bmQgd2hlcmUgYW4gYWN0aW9uIGlzIG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLiBSZWZp
bmVkIFlBTkcgZGF0YXN0b3JlcyB3aXRoIE1ldGEtZGF0YQ0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPlRo
ZSBkYXRhc3RvcmUgY29uY2VwdHVhbCBkaXNjdXNzaW9uIGlzIGNvbnRpbnVpbmcgaW4gTkVUTU9E
IFdHLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPkl0IGhhcyBiZWVuIHByb3Bvc2VkIHRoYXQgdGhlIGFy
Y2hpdGVjdHVyYWwgZGlzY3Vzc2lvbiBzaG91bGQgYmUgY29udGludWVkIGluIE5FVE1PRCBXRyBh
bmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAwMDk5Ij50aGUgcHJvdG9jb2wgcGFydCBhcyB3ZWxsIGFzIHRoZSBu
ZWNlc3NhcnkgY2hhbmdlcyB0byB0aGUgZGF0YXN0b3JlIGRlZmluaXRpb24gdG8gTkVUQ09ORiBS
RkMgc2hvdWxkIGJlIGRvbmUgaW4gTkVUQ09ORiBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+TWVobWV0ICZhbXA7IE1haGVzaDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_HE1PR0701MB2859D3E5221BFA50F460F16F91090HE1PR0701MB2859_--


From nobody Thu Jul 21 07:43:05 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC5D12D645 for ; Thu, 21 Jul 2016 07:43:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6BTeRaGcBcb for ; Thu, 21 Jul 2016 07:43:02 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0110.outbound.protection.outlook.com [104.47.0.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F4312D0C7 for ; Thu, 21 Jul 2016 07:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vuX4OCyG7wxbgjgGdmIsEJ3OVpylP7jB7UwxQ/AYBDw=; b=NRpYSJAdCV5T7GeZhq2DxVLxBCT/jl6EBi7aGskL7MwGL2Vsja+1aMVSG3GuG97Um84ld/EhX/hY0FYai9iV97OfRsTw0yOc+ag5KowszNQY6Sd0XZPHtZQZyUfFlIDXQf8EXR54j8bFhnrh7hBHvwFWyGqGHHgmYphpVMOp9ZA=
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Thu, 21 Jul 2016 14:42:57 +0000
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0544.014; Thu, 21 Jul 2016 14:42:57 +0000
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: "Ersue, Mehmet (Nokia - DE/Munich)" , "Benoit Claise" , Netconf 
Thread-Topic: NETCONF WG Session Summary and AIs from IETF #96
Thread-Index: AdHjXZVfsF5FWEfiQbu6LKyEzhI5HQAAHSdg
Date: Thu, 21 Jul 2016 14:42:57 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; 
x-originating-ip: [62.159.77.186]
x-ms-office365-filtering-correlation-id: c583cb44-9b06-44ad-f71f-08d3b1754e98
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2859; 6:2Qmr+lC1H+tNDH0uLgSymcpZ5vWINdPKSK1GmNe+Pe+5HRS5tbFA2zEmZmSSQ8LE++8hWvHbxWf5NzanzkEJZSWwM3/4zp7qFSD4/7MRBbf42MG2ilJHtwOKLKTEK7+l0C9ocTuY7jz4tQ3wXzQCw+l23leMqMTVJ0+qzdTfYlbLVVz9wfjvFhYqE0uYhN1O6J46AboaYMGkxLMlUC0aMpfthaDd4yTZAgc73HJtDtdXfQ6MRcp9M17fNlmeAY+DydyY4L0XgK8xP3ZrvE7j+nB6L/8oWjC9hB2V1JVvN5PasuEl6w+TnHHpnSS+9Z+Wa2ExHPstx6zXW11cLEIExg==; 5:v8Fi+VZQpMcybOIQn05ceN9m9m5hm/o75qD+dAPDSxNfEsws01GCZELQMtmbwDG0UIszPF2Zb3bMnFU03Kv/8RlVzdA4p2xm7e36Mu4R8ubfM+IVqCGGezbXjG2hblkmHUPN4GzwijO9BFohZtb6LQ==; 24:alMBKkL8EkDATmcTGyKiPK6JctdJFXL6g7o98JBy1BgaRVxCOoF4NTiH98ozV7v044fnrXBYVHEk5G6G3XUBqm+4OSPJfSDDOSzaEeXGazU=; 7:UKotSPOJIy+j9icx6OjzfpnVPpD0AgSdDX1gHdbOb+90/1yB9JQFcB+UbVsaE/oZhWs0F5vxY0woMM94ieMF+RE+1KysWBiY6nQR3/Ez879wTha9m8DUpRPO7gdk/colgCBS3COX8ESXCp0a2DyZivEb0b+SG5PoDwtM4ncTIJFFjXLAxD/BK+2NXEsfSGiKqyAbQVUd9kduktxcvOeMMdK7lAnnNXzkPNeed60kDCMagv6POCMjcPj8TBKJRuQK
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2859;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);  SRVR:HE1PR0701MB2859; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2859; 
x-forefront-prvs: 0010D93EFE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(279900001)(199003)(377454003)(189002)(68736007)(7906003)(3660700001)(3280700002)(105586002)(5002640100001)(77096005)(74316002)(86362001)(50986999)(19300405004)(76176999)(66066001)(7696003)(54356999)(7736002)(5003600100003)(2906002)(76576001)(19617315012)(3846002)(6116002)(102836003)(561944003)(5001770100001)(33656002)(7846002)(16236675004)(790700001)(97736004)(101416001)(87936001)(8676002)(122556002)(106356001)(19625215002)(19580405001)(10400500002)(586003)(19580395003)(2950100001)(2900100001)(9686002)(15975445007)(8936002)(92566002)(19625305001)(81156014)(81166006)(107886002)(19609705001)(189998001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2859; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2859B68A7A0C1DE806C01A9E91090HE1PR0701MB2859_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 14:42:57.4096 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2859
Archived-At: 
Subject: Re: [Netconf] NETCONF WG Session Summary and AIs from IETF #96
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 14:43:04 -0000

--_000_HE1PR0701MB2859B68A7A0C1DE806C01A9E91090HE1PR0701MB2859_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q29ycmVjdGlvbjoNClRoZSBORVRDT05GIHNlc3Npb24gd2FzIG9uIFdlZG5lc2RheSAxMDAwLTEy
MzAgQ0VULg0KDQpNZWhtZXQNCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVuaWNo
KQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMjEsIDIwMTYgNDozOSBQTQ0KVG86IEJlbm9pdCBDbGFp
c2UgPGJjbGFpc2VAY2lzY28uY29tPjsgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1Ympl
Y3Q6IFtOZXRjb25mXSBORVRDT05GIFdHIFNlc3Npb24gU3VtbWFyeSBhbmQgQUlzIGZyb20gSUVU
RiAjOTYNCg0KRGVhciBCZW5vaXQsIE5FVENPTkYgV0csDQoNCmJlbG93IGlzIHRoZSBORVRDT05G
IFdHIHNlc3Npb24gc3VtbWFyeSBhbmQgQUlzIGZyb20gSUVURiAjOTYuDQoNCj0+IFRoaXMgbWFp
bCBpcyBhdCB0aGUgc2FtZSB0aW1lIHRvIHZlcmlmeS92YWxpZGF0ZSB0aGUgZGlzY3Vzc2lvbiBy
ZXN1bHQgYW5kIGRlY2lzaW9ucyBmcm9tIHRoZSBJRVRGIDk2IE5FVENPTkYgc2Vzc2lvbi4NCj0+
IElmIHRoZXJlIGlzIG5vIHN0cm9uZyBvYmplY3Rpb24gd2Ugd2lsbCBpbXBsZW1lbnQgYXMgZGlz
Y3Vzc2VkLg0KDQpUaGUgTkVUQ09ORiBzZXNzaW9uIHRvb2sgcGxhY2Ugb24gTW9uZGF5LCBKdWx5
IDE4LCAyMDE2LCBmcm9tIDEwOjAwIOKAkyAxMjozMCBDRVQgQmVybGluLCBHZXJtYW55Lg0KDQot
IFdlIGhhZCBhcHByb3guIDEyMCsgcGFydGljaXBhbnRzIGluIHRoZSAyLjUgaG91ciBORVRDT05G
IHNlc3Npb24sDQotIFdlIHJldmlld2VkIHRoZSBzdGF0dXMgb2YgdGhlIFdHLA0KLSBXZSBoYWQg
YSBkaXNjdXNzaW9uIG9uIGNoYXJ0ZXJlZCBkb2N1bWVudHMuDQoNClRoZSByb3VnaCBub3RlcyBm
cm9tIHRoZSBFdGhlcnBhZCBhcmUgYXZhaWxhYmxlIGF0Og0KaHR0cDovL2V0aGVycGFkLnRvb2xz
LmlldGYub3JnOjkwMDAvcC9ub3Rlcy1pZXRmLTk2LW5ldGNvbmY/dXNlTW9ub3NwYWNlRm9udD10
cnVlDQoNCg0KQ2hhcnRlcmVkIGl0ZW1zOg0KICAgICAgMS4gUmVwb3J0IGZyb20gZG9jdW1lbnRz
IGFmdGVyIFdHTEM6IFJlc3Rjb25mLCBZYW5nLXBhdGNoIC0gQS4gQmllcm1hbiAoMTUgbWluLikN
CkFuZHkgd2lsbCBwcm92aWRlIGFuIHVwZGF0ZSBmb3IgUkVTVENPTkYgYW5kIFlBTkcgUGF0Y2gg
YnkgbmV4dCB3ZWVrLg0KDQogICAgICAyLiBTdWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBw
dXNoIHVwZGF0ZXMgLSBFcmljIFZvaXQgKDE1IG1pbikNCiAgICAgIDMuIFN1YnNjcmlwdGlvbnMg
Zm9yIEV2ZW50IE5vdGlmaWNhdGlvbnMgKFJGQyA1Mjc3YmlzKSAtIEVyaWMgVm9pdCAoMTUgbWlu
KQ0KICAgICAgNC4gTkVUQ09ORiBUcmFuc3BvcnQgZm9yIEV2ZW50IE5vdGlmaWNhdGlvbnMgLSBF
cmljIFZvaXQgKDEwIG1pbikNCiAgICAgIDUuIFJFU1RDT05GICYgSFRUUCBUcmFuc3BvcnQgZm9y
IEV2ZW50IE5vdGlmaWNhdGlvbnMgLSBFcmljIFZvaXQgKDUgbWluKQ0K4oCcWUFORyBQdXNo4oCd
IGRyYWZ0cyB3ZXJlIGRpc2N1c3NlZC4gVGhlIFdHIGFncmVlZCB0byBhZG9wdCB0aGUgdGhyZWUg
ZHJhZnRzIDUyNzdiaXMsIE5FVENPTkYgVHJhbnNwb3J0IGFuZCBSRVNUQ09ORiAmIEhUVFAgVHJh
bnNwb3J0Lg0KVGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnRzIHdpbGwgYmUgYWNjZXB0ZWQg
YXMgZHJhZnQtaWV0Zi4NCg0KICAgICAgNi4gU3lzdGVtIEtleWNoYWluIE1vZGVsIC0gSy4gV2F0
c2VuDQogICAgICA3LiBTU0ggQ2xpZW50IFNlcnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KICAgICAg
OC4gVExTIENsaWVudCBTZXJ2ZXIgTW9kZWwgLSBLLiBXYXRzZW4NCiAgICAgIDkuIE5FVENPTkYg
Q2xpZW50IFNlcnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KICAgICAxMC4gUkVTVENPTkYgQ2xpZW50
IFNlcnZlciBNb2RlbCAtIEsuIFdhdHNlbg0KICAgICAxMS4gWmVybyBUb3VjaCBQcm92aXNpb25p
bmcgZm9yIE5FVENPTkYgQ2FsbCBIb21lIChaZXJvVG91Y2gpIC0gSy4gV2F0c2VuDQpJc3N1ZSBk
aXNjdXNzaW9uLiBJc3N1ZXMgd2lsbCBiZSBhZGRyZXNzZWQgYW5kIGRyYWZ0cyB3aWxsIGJlIHVw
ZGF0ZWQgYXMgZGlzY3Vzc2VkLg0KQ2xpZW50IG1vZGVscyB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0
aGUgbmV4dCB2ZXJzaW9uLg0KDQpOb24tQ2hhcnRlcmVkIGl0ZW1zOg0KICAgICAgMS4gSTJSUyBz
dHJhd21hbiBwcm9wb3NhbCAtIFMuIEhhcmVzDQpTdWUgcHJlc2VudGVkIHRoZSBJMlJTIHJlcXVp
cmVtZW50cyBkb2N1bWVudGVkIGluIGVwaGVtZXJhbCBzdGF0ZSBkcmFmdC4gVGhlcmUgd2FzIG5v
IGZ1cnRoZXIgY29tbWVudHMuDQpUaGUgY2hhaXJzIGFza2VkIHRoZSBhdHRlbmRlZXMgdG8gY29t
bWVudCBhbmQgZGlzY3VzcyBpZiB0aGV5IHNlZSBhbiBpc3N1ZS4gT3RoZXJ3aXNlIHRoZXkgd2ls
bCBhcmUgc2VlbiBhcyBhY2NlcHRlZC4NClN1ZSBhZ3JlZWQgdG8gcHJvdmlkZSBhbiBvdmVydmll
dyBvbiB3aGljaCByZXF1aXJlbWVudHMgYXJlIGFkZHJlc3NlZCBpbiB3aGljaCBkcmFmdCBhbmQg
d2hlcmUgYW4gYWN0aW9uIGlzIG5lY2Vzc2FyeS4NCg0KICAgICAgMi4gUmVmaW5lZCBZQU5HIGRh
dGFzdG9yZXMgd2l0aCBNZXRhLWRhdGENClRoZSBkYXRhc3RvcmUgY29uY2VwdHVhbCBkaXNjdXNz
aW9uIGlzIGNvbnRpbnVpbmcgaW4gTkVUTU9EIFdHLg0KSXQgaGFzIGJlZW4gcHJvcG9zZWQgdGhh
dCB0aGUgYXJjaGl0ZWN0dXJhbCBkaXNjdXNzaW9uIHNob3VsZCBiZSBjb250aW51ZWQgaW4gTkVU
TU9EIFdHIGFuZA0KdGhlIHByb3RvY29sIHBhcnQgYXMgd2VsbCBhcyB0aGUgbmVjZXNzYXJ5IGNo
YW5nZXMgdG8gdGhlIGRhdGFzdG9yZSBkZWZpbml0aW9uIHRvIE5FVENPTkYgUkZDIHNob3VsZCBi
ZSBkb25lIGluIE5FVENPTkYgV0cuDQoNCk1laG1ldCAmIE1haGVzaA0KDQo=

--_000_HE1PR0701MB2859B68A7A0C1DE806C01A9E91090HE1PR0701MB2859_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5lbWFp
bHF1b3RlLCBsaS5lbWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTpl
bWFpbHF1b3RlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz
cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMENDO30NCnNwYW4uRW1haWxTdHls
ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOiMwMDAwQ0M7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6IzAwMDA5OTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7
DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjojMDAwMENDOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h
bDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOiMwMDAwOTk7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y
bWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzAwMDBDQzsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu
b3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyNA0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMDAwMDk5Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl
Om5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTI1
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDAwOTk7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv
bnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy
LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Q29ycmVjdGlvbjo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMDA5OSI+VGhlIE5FVENPTkYgc2Vzc2lvbiB3YXMgb24gV2VkbmVzZGF5IDEwMDAtMTIz
MCBDRVQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+
TWVobWV0DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0
Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVu
aWNoKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAyMSwgMjAxNiA0OjM5IFBNPGJy
Pg0KPGI+VG86PC9iPiBCZW5vaXQgQ2xhaXNlICZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs7IE5l
dGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtOZXRj
b25mXSBORVRDT05GIFdHIFNlc3Npb24gU3VtbWFyeSBhbmQgQUlzIGZyb20gSUVURiAjOTY8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMDA5OSI+RGVhciBCZW5vaXQsIE5FVENPTkYgV0csDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPmJlbG93IGlzIHRoZSBORVRDT05GIFdHIHNl
c3Npb24gc3VtbWFyeSBhbmQgQUlzIGZyb20gSUVURiAjOTYuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAwMDk5Ij49Jmd0OyBUaGlzIG1haWwgaXMgYXQgdGhlIHNhbWUgdGlt
ZSB0byB2ZXJpZnkvdmFsaWRhdGUgdGhlIGRpc2N1c3Npb24gcmVzdWx0IGFuZCBkZWNpc2lvbnMg
ZnJvbSB0aGUgSUVURiA5NiBORVRDT05GIHNlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPj0mZ3Q7
IElmIHRoZXJlIGlzIG5vIHN0cm9uZyBvYmplY3Rpb24gd2Ugd2lsbCBpbXBsZW1lbnQgYXMgZGlz
Y3Vzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+VGhlIE5F
VENPTkYgc2Vzc2lvbiB0b29rIHBsYWNlIG9uIE1vbmRheSwgSnVseSAxOCwgMjAxNiwgZnJvbSAx
MDowMCDigJMgMTI6MzAgQ0VUIEJlcmxpbiwgR2VybWFueS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+LSBXZSBoYWQgYXBwcm94LiAxMjAmIzQzOyBwYXJ0aWNp
cGFudHMgaW4gdGhlIDIuNSBob3VyIE5FVENPTkYgc2Vzc2lvbiw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+
LSBXZSByZXZpZXdlZCB0aGUgc3RhdHVzIG9mIHRoZSBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+LSBX
ZSBoYWQgYSBkaXNjdXNzaW9uIG9uIGNoYXJ0ZXJlZCBkb2N1bWVudHMuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAw
OTkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5UaGUgcm91Z2ggbm90ZXMgZnJvbSB0aGUgRXRo
ZXJwYWQgYXJlIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PGEgaHJlZj0iaHR0cDov
L2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9ub3Rlcy1pZXRmLTk2LW5ldGNvbmY/dXNl
TW9ub3NwYWNlRm9udD10cnVlIj5odHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9w
L25vdGVzLWlldGYtOTYtbmV0Y29uZj91c2VNb25vc3BhY2VGb250PXRydWU8L2E+DQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw
MDk5Ij5DaGFydGVyZWQgaXRlbXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAxLiBSZXBvcnQgZnJvbSBkb2N1bWVudHMgYWZ0ZXIgV0dMQzogUmVzdGNv
bmYsIFlhbmctcGF0Y2ggLSBBLiBCaWVybWFuICgxNSBtaW4uKTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5B
bmR5IHdpbGwgcHJvdmlkZSBhbiB1cGRhdGUgZm9yIFJFU1RDT05GIGFuZCBZQU5HIFBhdGNoIGJ5
IG5leHQgd2Vlay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLiBTdWJzY3JpYmluZyB0byBZQU5HIGRhdGFz
dG9yZSBwdXNoIHVwZGF0ZXMgLSBFcmljIFZvaXQgKDE1IG1pbik8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuIFN1YnNjcmlwdGlvbnMgZm9yIEV2ZW50
IE5vdGlmaWNhdGlvbnMgKFJGQyA1Mjc3YmlzKSAtIEVyaWMgVm9pdCAoMTUgbWluKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMDAwMDk5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4gTkVUQ09ORiBUcmFu
c3BvcnQgZm9yIEV2ZW50IE5vdGlmaWNhdGlvbnMgLSBFcmljIFZvaXQgKDEwIG1pbik8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMDA5OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUuIFJFU1RDT05GICZh
bXA7IEhUVFAgVHJhbnNwb3J0IGZvciBFdmVudCBOb3RpZmljYXRpb25zIC0gRXJpYyBWb2l0ICg1
IG1pbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+4oCcWUFORyBQdXNo4oCdIGRyYWZ0cyB3ZXJlIGRpc2N1
c3NlZC4gVGhlIFdHIGFncmVlZCB0byBhZG9wdCB0aGUgdGhyZWUgZHJhZnRzIDUyNzdiaXMsIE5F
VENPTkYgVHJhbnNwb3J0IGFuZCBSRVNUQ09ORiAmYW1wOyBIVFRQIFRyYW5zcG9ydC4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAwMDk5Ij5UaGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdHMgd2lsbCBiZSBhY2Nl
cHRlZCBhcyBkcmFmdC1pZXRmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MDA5OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDYuIFN5c3RlbSBLZXljaGFpbiBN
b2RlbCAtIEsuIFdhdHNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgNy4gU1NIIENsaWVudCBTZXJ2ZXIgTW9kZWwgLSBLLiBXYXRzZW48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzAwMDA5OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDguIFRMUyBDbGllbnQgU2Vy
dmVyIE1vZGVsIC0gSy4gV2F0c2VuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OS4gTkVUQ09ORiBDbGllbnQgU2VydmVyIE1vZGVsIC0gSy4g
V2F0c2VuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
MTAuIFJFU1RDT05GIENsaWVudCBTZXJ2ZXIgTW9kZWwgLSBLLiBXYXRzZW4NCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MDAwMDk5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsxMS4gWmVybyBUb3VjaCBQcm92
aXNpb25pbmcgZm9yIE5FVENPTkYgQ2FsbCBIb21lIChaZXJvVG91Y2gpIC0gSy4gV2F0c2VuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDAwOTkiPklzc3VlIGRpc2N1c3Npb24uIElzc3VlcyB3aWxsIGJlIGFkZHJlc3Nl
ZCBhbmQgZHJhZnRzIHdpbGwgYmUgdXBkYXRlZCBhcyBkaXNjdXNzZWQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAw
OTkiPkNsaWVudCBtb2RlbHMgd2lsbCBiZSBhZGRyZXNzZWQgaW4gdGhlIG5leHQgdmVyc2lvbi48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPk5vbi1DaGFydGVyZWQg
aXRlbXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MS4gSTJSUyBzdHJhd21hbiBwcm9w
b3NhbCAtIFMuIEhhcmVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+U3VlIHByZXNlbnRlZCB0aGUgSTJS
UyByZXF1aXJlbWVudHMgZG9jdW1lbnRlZCBpbiBlcGhlbWVyYWwgc3RhdGUgZHJhZnQuIFRoZXJl
IHdhcyBubyBmdXJ0aGVyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5UaGUgY2hhaXJzIGFz
a2VkIHRoZSBhdHRlbmRlZXMgdG8gY29tbWVudCBhbmQgZGlzY3VzcyBpZiB0aGV5IHNlZSBhbiBp
c3N1ZS4gT3RoZXJ3aXNlIHRoZXkgd2lsbCBhcmUgc2VlbiBhcyBhY2NlcHRlZC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzAwMDA5OSI+U3VlIGFncmVlZCB0byBwcm92aWRlIGFuIG92ZXJ2aWV3IG9uIHdoaWNoIHJlcXVp
cmVtZW50cyBhcmUgYWRkcmVzc2VkIGluIHdoaWNoIGRyYWZ0IGFuZCB3aGVyZSBhbiBhY3Rpb24g
aXMgbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuIFJlZmluZWQgWUFORyBkYXRhc3RvcmVz
IHdpdGggTWV0YS1kYXRhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+VGhlIGRhdGFzdG9yZSBjb25jZXB0
dWFsIGRpc2N1c3Npb24gaXMgY29udGludWluZyBpbiBORVRNT0QgV0cuDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MDA5OSI+SXQgaGFzIGJlZW4gcHJvcG9zZWQgdGhhdCB0aGUgYXJjaGl0ZWN0dXJhbCBkaXNjdXNz
aW9uIHNob3VsZCBiZSBjb250aW51ZWQgaW4gTkVUTU9EIFdHIGFuZA0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAw
OTkiPnRoZSBwcm90b2NvbCBwYXJ0IGFzIHdlbGwgYXMgdGhlIG5lY2Vzc2FyeSBjaGFuZ2VzIHRv
IHRoZSBkYXRhc3RvcmUgZGVmaW5pdGlvbiB0byBORVRDT05GIFJGQyBzaG91bGQgYmUgZG9uZSBp
biBORVRDT05GIFdHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAwMENDIj5NZWhtZXQgJmFtcDsgTWFoZXNoPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_HE1PR0701MB2859B68A7A0C1DE806C01A9E91090HE1PR0701MB2859_--


From nobody Thu Jul 21 07:57:56 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5323F12D5F9 for ; Thu, 21 Jul 2016 07:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvXA7L8TloHc for ; Thu, 21 Jul 2016 07:57:53 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312B912D14A for ; Thu, 21 Jul 2016 07:57:47 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id x130so117213352vkc.0 for ; Thu, 21 Jul 2016 07:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sI5mDToixgyRaQnYVXOavTa+t63y6KCo5RIqE5NTLtA=; b=imP4xFT9QyjDiZvMaNoX6IOw9eLeG1LmVuKOgEFv52cOrFdYFIkVk0lBB1UIppv7ri h0v8zc0S+l2Jwjm2+0CO2J1R9y3F6UugBpQpWn0z0M0KRVLp8NaaSC6N4Yr7ilu3ia5Z UYx6/zm8sa0AD0wmUlXVzfRcGAyr5n2uou4KUyeMejFLf2atlIv3r6NR7h25zjG3GjYF rpzRyoBfHJcBPqppP11EcHSQz5HtdTEJETo0wrrgujD0lqORSALxSGHTiPcdg/TEkq1q BA+TNnub++mmQtbFDWw4qAyM5/KxNS/U1nsVjIRcEgemkHOrm8YTv5+GAwyvxwoY2P3B s80g==
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; bh=sI5mDToixgyRaQnYVXOavTa+t63y6KCo5RIqE5NTLtA=; b=SssrroWn4S5pTVIoUhN3n5QexwaUJNmSPjO50h8EFVIx4sxtZgw1p33THS9jAX5KR+ qEmuPNhDaG2GgoXjYCcXva2uvunCj2kmKrivdCZf9hDEXJ7Uh3+7g0JGKSDXo4n1FuIr p36jT3bqK6/h+tf+RsFUcdA0Q5/pt2AE3WSPw/Z2qDMsPMA+YATVAzjP/dSkAgF6PBZr P2w2qedHsnolbeE2qJsKB6CR/i7b3aDqNSNxdQIXbaES/FCgdw7S1gigRPX68Xf6i5Mg fNi4ZhfkOUlquavYFoYLoMOIHpFPFHaS3pPfTXJeezjYnbdbMW79Pf1JHJJNyxLR4yYf PpMA==
X-Gm-Message-State: ALyK8tJMj2UG5JYRpjy/9PRIdcU5Kalx9m+XIJMiIZt3BkRF2ilsJ62e04uvaXhs1cfDNlMOMtK9qhASWafGvA==
X-Received: by 10.31.231.3 with SMTP id e3mr26716718vkh.13.1469113066293; Thu, 21 Jul 2016 07:57:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Thu, 21 Jul 2016 07:57:45 -0700 (PDT)
In-Reply-To: 
References:  
From: Andy Bierman 
Date: Thu, 21 Jul 2016 07:57:45 -0700
Message-ID: 
To: "Ersue, Mehmet (Nokia - DE/Munich)" 
Content-Type: multipart/alternative; boundary=94eb2c095ca4739b420538268ac3
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] NETCONF WG Session Summary and AIs from IETF #96
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 14:57:55 -0000

--94eb2c095ca4739b420538268ac3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I think I said in the meeting the RESTCONF and YANG Patch drafts
will be updated 2 weeks after the IETF (by Aug. 6).  It may get done
sooner, or a bit later if some remaining review comments require
clarification.


Andy


On Thu, Jul 21, 2016 at 7:42 AM, Ersue, Mehmet (Nokia - DE/Munich) <
mehmet.ersue@nokia.com> wrote:

> Correction:
>
> The NETCONF session was on Wednesday 1000-1230 CET.
>
>
>
> Mehmet
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Ersue,
> Mehmet (Nokia - DE/Munich)
> *Sent:* Thursday, July 21, 2016 4:39 PM
> *To:* Benoit Claise ; Netconf 
> *Subject:* [Netconf] NETCONF WG Session Summary and AIs from IETF #96
>
>
>
> Dear Benoit, NETCONF WG,
>
>
>
> below is the NETCONF WG session summary and AIs from IETF #96.
>
>
>
> =3D> This mail is at the same time to verify/validate the discussion resu=
lt
> and decisions from the IETF 96 NETCONF session.
>
> =3D> If there is no strong objection we will implement as discussed.
>
>
>
> The NETCONF session took place on Monday, July 18, 2016, from 10:00 =E2=
=80=93
> 12:30 CET Berlin, Germany.
>
>
>
> - We had approx. 120+ participants in the 2.5 hour NETCONF session,
>
> - We reviewed the status of the WG,
>
> - We had a discussion on chartered documents.
>
>
>
> The rough notes from the Etherpad are available at:
>
>
> http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-netconf?useMonospaceF=
ont=3Dtrue
>
>
>
>
>
> Chartered items:
>
>       1. Report from documents after WGLC: Restconf, Yang-patch - A.
> Bierman (15 min.)
>
> Andy will provide an update for RESTCONF and YANG Patch by next week.
>
>
>
>       2. Subscribing to YANG datastore push updates - Eric Voit (15 min)
>
>       3. Subscriptions for Event Notifications (RFC 5277bis) - Eric Voit
> (15 min)
>
>       4. NETCONF Transport for Event Notifications - Eric Voit (10 min)
>
>       5. RESTCONF & HTTP Transport for Event Notifications - Eric Voit (5
> min)
>
> =E2=80=9CYANG Push=E2=80=9D drafts were discussed. The WG agreed to adopt=
 the three drafts
> 5277bis, NETCONF Transport and RESTCONF & HTTP Transport.
>
> The next version of the drafts will be accepted as draft-ietf.
>
>
>
>       6. System Keychain Model - K. Watsen
>
>       7. SSH Client Server Model - K. Watsen
>
>       8. TLS Client Server Model - K. Watsen
>
>       9. NETCONF Client Server Model - K. Watsen
>
>      10. RESTCONF Client Server Model - K. Watsen
>
>      11. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K.
> Watsen
>
> Issue discussion. Issues will be addressed and drafts will be updated as
> discussed.
>
> Client models will be addressed in the next version.
>
>
>
> Non-Chartered items:
>
>       1. I2RS strawman proposal - S. Hares
>
> Sue presented the I2RS requirements documented in ephemeral state draft.
> There was no further comments.
>
> The chairs asked the attendees to comment and discuss if they see an
> issue. Otherwise they will are seen as accepted.
>
> Sue agreed to provide an overview on which requirements are addressed in
> which draft and where an action is necessary.
>
>
>
>       2. Refined YANG datastores with Meta-data
>
> The datastore conceptual discussion is continuing in NETMOD WG.
>
> It has been proposed that the architectural discussion should be continue=
d
> in NETMOD WG and
>
> the protocol part as well as the necessary changes to the datastore
> definition to NETCONF RFC should be done in NETCONF WG.
>
>
>
> Mehmet & Mahesh
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--94eb2c095ca4739b420538268ac3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I think I said in the meeting the R=
ESTCONF and YANG Patch drafts
will be updated 2 weeks after the I=
ETF (by Aug. 6).=C2=A0 It may get done
sooner, or a bit later if =
some remaining review comments require clarification.

<=
div>
Andy


On Thu, Jul 21, 2016 at 7:42 AM, Ersue, Me=
hmet (Nokia - DE/Munich) <mehmet.ersue@nokia.com> wrote=
:











Correction:


The NETCONF session was on Wednesday =
1000-1230 CET.


=C2=A0




Mehmet





=C2=A0






From: Netconf [mailto:netconf-bounces@ietf.org]
On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)

Sent: Thursday, July 21, 2016 4:39 PM

To: Benoit Claise <bclaise@cisco.com>; Netconf <netconf@ietf.org>

Subject: [Netconf] NETCONF WG Session Summary and AIs from IETF #96<=
u>






=C2=A0


Dear Benoit, NETCONF WG,



=C2=A0


below is the NETCONF WG session summa=
ry and AIs from IETF #96.


=C2=A0


=3D> This mail is at the same time=
 to verify/validate the discussion result and decisions from the IETF 96 NE=
TCONF session.


=3D> If there is no strong objecti=
on we will implement as discussed.


=C2=A0


The NETCONF session took place on Mon=
day, July 18, 2016, from 10:00 =E2=80=93 12:30 CET Berlin, Germany.



=C2=A0


- We had approx. 120+ participants in=
 the 2.5 hour NETCONF session,


- We reviewed the status of the WG,


- We had a discussion on chartered do=
cuments.


=C2=A0


The rough notes from the Etherpad are=
 available at:


http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-netconf?useMonospaceF=
ont=3Dtrue



=C2=A0


=C2=A0


Chartered items:=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. Rep=
ort from documents after WGLC: Restconf, Yang-patch - A. Bierman (15 min.)<=
u>


Andy will provide an update for RESTC=
ONF and YANG Patch by next week.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. Sub=
scribing to YANG datastore push updates - Eric Voit (15 min)<=
/span>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3. Sub=
scriptions for Event Notifications (RFC 5277bis) - Eric Voit (15 min)


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4. NET=
CONF Transport for Event Notifications - Eric Voit (10 min)


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5. RES=
TCONF & HTTP Transport for Event Notifications - Eric Voit (5 min)


=E2=80=9CYANG Push=E2=80=9D drafts we=
re discussed. The WG agreed to adopt the three drafts 5277bis, NETCONF Tran=
sport and RESTCONF & HTTP Transport.



The next version of the drafts will b=
e accepted as draft-ietf.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6. Sys=
tem Keychain Model - K. Watsen


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7. SSH=
 Client Server Model - K. Watsen


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 8. TLS=
 Client Server Model - K. Watsen



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A09=
. NETCONF Client Server Model - K. Watsen



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010. RES=
TCONF Client Server Model - K. Watsen



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A011. Zer=
o Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen


Issue discussion. Issues will be addr=
essed and drafts will be updated as discussed.


Client models will be addressed in th=
e next version.


=C2=A0


Non-Chartered items:=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01=
. I2RS strawman proposal - S. Hares



Sue presented the I2RS requirements d=
ocumented in ephemeral state draft. There was no further comments.


The chairs asked the attendees to com=
ment and discuss if they see an issue. Otherwise they will are seen as acce=
pted.


Sue agreed to provide an overview on =
which requirements are addressed in which draft and where an action is nece=
ssary.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. Ref=
ined YANG datastores with Meta-data



The datastore conceptual discussion i=
s continuing in NETMOD WG.



It has been proposed that the archite=
ctural discussion should be continued in NETMOD WG and



the protocol part as well as the nece=
ssary changes to the datastore definition to NETCONF RFC should be done in =
NETCONF WG.


=C2=A0




Mehmet & Mahesh






=C2=A0









_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c095ca4739b420538268ac3--


From nobody Thu Jul 21 08:17:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9054512D67C for ; Thu, 21 Jul 2016 08:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.74
X-Spam-Level: *
X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, WEIRD_PORT=0.001] autolearn=no autolearn_force=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 g1ZUCFj4X6DT for ; Thu, 21 Jul 2016 08:17:29 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB1112D674 for ; Thu, 21 Jul 2016 08:17:28 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.162.131; 
From: "Susan Hares" 
To: "'Ersue, Mehmet \(Nokia - DE/Munich\)'" , "'Benoit Claise'" , "'Netconf'" 
References: 
In-Reply-To: 
Date: Thu, 21 Jul 2016 11:16:50 -0400
Message-ID: <21b501d1e362$e8ea3ba0$babeb2e0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_21B6_01D1E341.61DB33B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHXBrIRSlJvEG0j2seW1amcSABDFaAYuESA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [Netconf] NETCONF WG Session Summary and AIs from IETF #96
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 15:17:30 -0000

This is a multipart message in MIME format.

------=_NextPart_000_21B6_01D1E341.61DB33B0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Mahesh and Mehmet:=20

=20

This is an excellent summary for my talk.

=20

Sue Hares

=20

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, =
Mehmet (Nokia - DE/Munich)
Sent: Thursday, July 21, 2016 10:39 AM
To: Benoit Claise; Netconf
Subject: [Netconf] NETCONF WG Session Summary and AIs from IETF #96

=20

Dear Benoit, NETCONF WG,=20

=20

below is the NETCONF WG session summary and AIs from IETF #96.

=20

=3D> This mail is at the same time to verify/validate the discussion =
result and decisions from the IETF 96 NETCONF session.

=3D> If there is no strong objection we will implement as discussed.

=20

The NETCONF session took place on Monday, July 18, 2016, from 10:00 =
=E2=80=93 12:30 CET Berlin, Germany.=20

=20

- We had approx. 120+ participants in the 2.5 hour NETCONF session,

- We reviewed the status of the WG,

- We had a discussion on chartered documents.

=20

The rough notes from the Etherpad are available at:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-netconf?useMonospaceF=
ont=3Dtrue=20

=20

=20

Chartered items:

      1. Report from documents after WGLC: Restconf, Yang-patch - A. =
Bierman (15 min.)

Andy will provide an update for RESTCONF and YANG Patch by next week.

=20

      2. Subscribing to YANG datastore push updates - Eric Voit (15 min)

      3. Subscriptions for Event Notifications (RFC 5277bis) - Eric Voit =
(15 min)

      4. NETCONF Transport for Event Notifications - Eric Voit (10 min)

      5. RESTCONF & HTTP Transport for Event Notifications - Eric Voit =
(5 min)

=E2=80=9CYANG Push=E2=80=9D drafts were discussed. The WG agreed to =
adopt the three drafts 5277bis, NETCONF Transport and RESTCONF & HTTP =
Transport.=20

The next version of the drafts will be accepted as draft-ietf.

=20

      6. System Keychain Model - K. Watsen

      7. SSH Client Server Model - K. Watsen

      8. TLS Client Server Model - K. Watsen=20

      9. NETCONF Client Server Model - K. Watsen=20

     10. RESTCONF Client Server Model - K. Watsen=20

     11. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. =
Watsen

Issue discussion. Issues will be addressed and drafts will be updated as =
discussed.

Client models will be addressed in the next version.

=20

Non-Chartered items:     =20

      1. I2RS strawman proposal - S. Hares=20

Sue presented the I2RS requirements documented in ephemeral state draft. =
There was no further comments.

The chairs asked the attendees to comment and discuss if they see an =
issue. Otherwise they will are seen as accepted.

Sue agreed to provide an overview on which requirements are addressed in =
which draft and where an action is necessary.

=20

      2. Refined YANG datastores with Meta-data=20

The datastore conceptual discussion is continuing in NETMOD WG.=20

It has been proposed that the architectural discussion should be =
continued in NETMOD WG and=20

the protocol part as well as the necessary changes to the datastore =
definition to NETCONF RFC should be done in NETCONF WG.

=20

Mehmet & Mahesh

=20


------=_NextPart_000_21B6_01D1E341.61DB33B0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Mahesh and Mehmet: 
 
This is an excellent summary for my talk.
 
Sue Hares
 
From:=
 =
Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, =
Mehmet (Nokia - DE/Munich)
Sent: Thursday, July 21, 2016 10:39 =
AM
To: Benoit Claise; Netconf
Subject: [Netconf] =
NETCONF WG Session Summary and AIs from IETF =
#96
 
Dear Benoit, NETCONF WG, 
 
below is the NETCONF WG session summary and AIs from IETF =
#96.
 
=3D> This mail is at the same time to verify/validate the =
discussion result and decisions from the IETF 96 NETCONF =
session.
=3D> If there is no strong objection we will implement as =
discussed.
 
The NETCONF session took place on Monday, July 18, 2016, from 10:00 =
=E2=80=93 12:30 CET Berlin, Germany. 
 
- We had approx. 120+ participants in the 2.5 hour NETCONF =
session,
- We reviewed the status of the WG,
- We had a discussion on chartered documents.
 
The rough notes from the Etherpad are available =
at:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-n=
etconf?useMonospaceFont=3Dtrue 
 
 
Chartered items:
      1. Report from documents after WGLC: =
Restconf, Yang-patch - A. Bierman (15 min.)
Andy will provide an update for RESTCONF and YANG Patch by next =
week.
 
      2. Subscribing to YANG datastore push =
updates - Eric Voit (15 min)
      3. Subscriptions for Event =
Notifications (RFC 5277bis) - Eric Voit (15 min)
      4. NETCONF Transport for Event =
Notifications - Eric Voit (10 min)
      5. RESTCONF & HTTP Transport for =
Event Notifications - Eric Voit (5 min)
=E2=80=9CYANG Push=E2=80=9D drafts were discussed. The WG agreed to =
adopt the three drafts 5277bis, NETCONF Transport and RESTCONF & =
HTTP Transport. 
The next version of the drafts will be accepted as =
draft-ietf.
 
      6. System Keychain Model - K. =
Watsen
      7. SSH Client Server Model - K. =
Watsen
      8. TLS Client Server Model - K. Watsen =

      9. NETCONF Client Server Model - =
K. Watsen 
     10. RESTCONF Client Server Model - K. =
Watsen 
     11. Zero Touch Provisioning for NETCONF =
Call Home (ZeroTouch) - K. Watsen
Issue discussion. Issues will be addressed and drafts will be updated =
as discussed.
Client models will be addressed in the next =
version.
 
Non-Chartered items:      =

      1. I2RS strawman proposal - S. =
Hares 
Sue presented the I2RS requirements documented in ephemeral state =
draft. There was no further comments.
The chairs asked the attendees to comment and discuss if they see an =
issue. Otherwise they will are seen as accepted.
Sue agreed to provide an overview on which requirements are addressed =
in which draft and where an action is necessary.
 
      2. Refined YANG datastores with =
Meta-data 
The datastore conceptual discussion is continuing in NETMOD WG. =

It has been proposed that the architectural discussion should be =
continued in NETMOD WG and 
the protocol part as well as the necessary changes to the datastore =
definition to NETCONF RFC should be done in NETCONF =
WG.
 
Mehmet & Mahesh
 =


------=_NextPart_000_21B6_01D1E341.61DB33B0--


From nobody Thu Jul 21 12:36:08 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0512D8A5 for ; Thu, 21 Jul 2016 12:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level: 
X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRX-eUWMMIol for ; Thu, 21 Jul 2016 12:36:05 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AB812D1DA for ; Thu, 21 Jul 2016 12:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11899; q=dns/txt; s=iport; t=1469129765; x=1470339365; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vEEUckSTylI6Ow10O+vSVwK9GKrlb2KQLZG1qKUJz5M=; b=k1WgTXXE/QOIa5u+1lbMNy5vzQLdblE6QtUvSAT2Arutyc83lYk2ZP4g Pb8yD/XyYOpbouQAseCGsDz1Te7EMhiiC1ruSEi6LjhA716VpoEd+9Pc/ 0uB9+sySbJL20oipJhcHRNfPg3NWIp4EFg4YtnizSZxzGaCCVZ4jO6Ad9 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgB2I5FX/5pdJa1dgnFOVnwGs1GFB?= =?us-ascii?q?IF7JIV2AoEwOBQBAQEBAQEBZRwLhFwBAQUdBAELOyECAQgRBAEBDgIYAgMCMhQ?= =?us-ascii?q?JCAEBBA8ECIgoDpJ5nRsBjVkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2Ed?= =?us-ascii?q?oJIgl0Fk2SFQgGGFYhOj0GQIAEeNoNzbgaGeH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,400,1464652800";  d="scan'208,217";a="298879087"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 19:36:04 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6LJa38W006479 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 21 Jul 2016 19:36:04 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 15:36:03 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 15:36:03 -0400
From: "Eric Voit (evoit)" 
To: "netconf@ietf.org" 
Thread-Topic: Subscribing to Network Elements @ IETF96 - Thursday 10AM
Thread-Index: AdHdN/cd07bshjPUTCyz8ZfQi3+MlAGTQAXA
Date: Thu, 21 Jul 2016 19:36:03 +0000
Message-ID: <66d71580646b424a83d05753c46c6614@XCH-RTP-013.cisco.com>
References: <09d23b6a25784819b933f433b733c47d@XCH-RTP-013.cisco.com>
In-Reply-To: <09d23b6a25784819b933f433b733c47d@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.203.80]
Content-Type: multipart/alternative; boundary="_000_66d71580646b424a83d05753c46c6614XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Subscribing to Network Elements @ IETF96 - Thursday 10AM
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jul 2016 19:36:07 -0000

--_000_66d71580646b424a83d05753c46c6614XCHRTP013ciscocom_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

Thanks to those of you who came to the Technology Intro session today.   As=
 promised, materials are here:
https://github.com/netconf-wg/yang-push/blob/master/Subscriptions-Intro-IET=
F96.ppt

Slides include:
Two Views of the Network=1B$B!G=1B(Bs Job
Must have Alternative to Polling
Generalized Publisher Capabilities
Consumption Models
Applicability beyond the Network Element
Event Notifications =1B$B!b=1B(B Raw Datastore Objects
When to use Event Notifications or YANG Datastore Push
Some Use Cases
Event & YANG Subscription Drafts
Subscription Drafts in Layered Framework
Context with OC-Telemetry.yang
Requirements of RFC 7923
Dampening Eventing vs. Periodic Behavior
Prioritization of Subscriptions
Reviewing the YANG Models
rfc5277bis
yang-push

Thanks,
Eric & Alex

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo=
it)
Sent: Wednesday, July 13, 2016 2:54 PM
To: netconf@ietf.org
Subject: [Netconf] Subscribing to Network Elements @ IETF96 - Thursday 10AM

A NETCONF agenda item for Wednesday will be the set of Subscription drafts.=
   A call for adoption will be requested by the authors on three of these d=
rafts.  One has already been adopted.  Because these drafts are coupled, we=
 are having an Intro session for those of you who haven=1B$B!G=1B(Bt follow=
ed this daily and would like to learn more.

               IETF-96
Thursday  10:00-11:30AM
               Tegel Conference Room

Material covered:

               Requirements for Subscription to YANG Datastores
RFC 7923

Subscriptions for Event Notifications  (RFC5277bis)
draft-gonzalez-netconf-5277bis


YANG Datastore Push

draft-ietf-netconf-yang-push

NETCONF Transport for Event Notifications
draft-gonzalez-netconf-event-notifications

RESTCONF & HTTP Transport for Event Notifications
draft-voit-netconf-restconf-notif

Thanks!
Eric (on behalf of the authors and contributors)

--_000_66d71580646b424a83d05753c46c6614XCHRTP013ciscocom_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable











Thanks to those of you w=
ho came to the Technology Intro session today.   As promised, mat=
erials are here:


ht=
tps://github.com/netconf-wg/yang-push/blob/master/Subscriptions-Intro-IETF9=
6.ppt


 


Slides include:


Two Views of the Network=1B$B!G=1B(Bs Job


Must have Alternative to Polling


Generalized Publisher Capabilities


Consumption Models


Applicability beyond the Network Element


Event Notifications =1B$B!b=1B(B Raw Datastore Objects=



When to use Event Notifications or YANG Datastore Push=



Some Use Cases


Event & YANG Subscription Drafts


Subscription Drafts in Layered Framework


Context with OC-Telemetry.yang


Requirements of RFC 7923


Dampening Eventing vs. Periodic Behavior


Prioritization of Subscriptions


Reviewing the YANG Models


rfc5277bis


yang-push


 =



Thanks, 


Eric & Alex


 








From: Netconf =
[mailto:netconf-bounces@ietf.org]
On Behalf Of Eric Voit (evoit)

Sent: Wednesday, July 13, 2016 2:54 PM

To: netconf@ietf.org

Subject: [Netconf] Subscribing to Network Elements @ IETF96 - Thursd=
ay 10AM






 


A NETCONF agenda item for Wednesday will be the set =
of Subscription drafts.   A call for adoption will be requested b=
y the authors on three of these drafts.  One has already been adopted.=
  Because these drafts are coupled, we are having
 an Intro session for those of you who haven=1B$B!G=1B(Bt followed this dai=
ly and would like to learn more. 



 


        &nbs=
p;      IETF-96


Thursday  10:00-11:3=
0AM


        &nbs=
p;      Tegel Conference Room


 


Material covered:


 


        &nbs=
p;      Requirements for Subscription to YANG Data=
stores


RFC 7923 



 


Subscriptions for Event N=
otifications  (RFC5277bis)


draft-gonzalez-netconf-=
5277bis


 


YANG Datastore Push 


draft-ietf-netconf-yan=
g-push


 


NETCONF Transport for Eve=
nt Notifications


draft-gonza=
lez-netconf-event-notifications 



 


RESTCONF & HTTP Trans=
port for Event Notifications


draft-voit-netconf-r=
estconf-notif


 


Thanks!


Eric (on behalf of the 
authors and contributors)








--_000_66d71580646b424a83d05753c46c6614XCHRTP013ciscocom_--


From nobody Fri Jul 22 03:13:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB88712DF82 for ; Fri, 22 Jul 2016 03:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3ZjzuD96g-3G for ; Fri, 22 Jul 2016 03:13:19 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FED12DF77 for ; Fri, 22 Jul 2016 03:13:18 -0700 (PDT)
X-AuditID: c1b4fb30-f79486d0000069d0-0b-5791f1bc9365
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.FD.27088.CB1F1975; Fri, 22 Jul 2016 12:13:16 +0200 (CEST)
Received: from [100.94.32.149] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.294.0; Fri, 22 Jul 2016 12:13:14 +0200
To: Jan Lindblad , Xiang Li 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericss on.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com> 
From: Balazs Lengyel 
Message-ID: <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>
Date: Fri, 22 Jul 2016 12:13:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2K7ve6ejxPDDfp/ilj8n9XHaDF1021W i2+b/jA7MHssWfKTyePhkg4Wj42/FrMEMEdx2aSk5mSWpRbp2yVwZTx6PIW9YFJlxYTpXawN jO8Duxg5OSQETCR2z7rHDmGLSVy4t56ti5GLQ0jgCKPEpqk/GSGc1YwSy5YeYwSpEhYIl3j7 dA0biC0i4CKx4MUfVoiiVg6J578/gyWYBeQkFv/oYQKx2QSMJKb2n2cBsXkF7CXufnsHto5F QFViXutHMFtUIEai8fZhdogaQYmTM5+A1XMK2EmcnvWeFWKmhkTrnLnsELa8RPPW2cwgthBQ /OGFv6wTGAVnIWmfhaRlFpKWBYzMqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECw/jglt8G OxhfPnc8xCjAwajEw7uAd2K4EGtiWXFl7iFGCQ5mJRHeiPdAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYylkzq39yttd22ouLcgsH/zrs+HHV6fuXKo 44SC/JlXuRGn9V/4sc0M27Q4nqs1JCtUsOTAxc+z2z+2CDZGlt35u8ZhlWwK64prG35K6UQu DHN6GMdxLvvdnCXimR9/fJ9TK/a/LvWgZ8zNeZbd060+b2s1yHqk+dZ/+7cv4rIS8t2Ntgkf Jy5XYinOSDTUYi4qTgQA40CxtF8CAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2016 10:13:22 -0000


  
    
  
  
    
Hello, 

    

    
We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.  I hope we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation. (Which is a slight
      violation of Netconf-6241, which we should accept.)

    

    
So I propose the following errata to rfc6020bis.

    
As for non-presence containers the presence of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:

    
- an <edit-config>  create operation for a non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>  delete operation for a non-presence
      container MUST succeed even if the container does not exist.  

      - an <edit-config>  operation with default-operation=none
      MUST succeed even if one or more  non-presence containers do not
      exist. 

    

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for
      organizing the hierarchy they SHOULD NOT have any must
      substatements.

    IMO the above rules remove ambiguity and follow the current
    philosophy of  RFC6020bis. 

    If we have a basic agreement I can formulate the text correctly.

    

    I don't know whether similar updates are needed for RestConf.

    regards Balazs

    

    PS. I still believe introducing NP containers was a mistake, however
    they are here to stay.  

    

    
On 2016-07-21 09:17, Jan Lindblad
      wrote:

    

    

      
      Xiang,
      


      

      

        

          

            

              

                
Are
                    you saying that since a NP-container is merely a
                    structure node, not config in any way, so
                    creating/deleting it explicitly (and repeatedly) is
                    equivalent to a “no-op†that will always succeed
                    because doing so has no effect on the server’s
                    config in any way? 

              

            

          

          


          

          
That's correct. "Creating" an object with zero bits of
            information is a no-op.

          


          

          

            

              

              
If the
                  sever has the following example config:

              
<mycontainer>

              
   
                   <child  ... bla..bla…configs>

              
</mycontainer>

              
 

              
 

              
If a
                  client issues an edit-config with:

              
< mycontainer operation="delete">

              
 

              
The
                  server returns “okâ€,

              
 

              
If then
                  again  the client attempts:

              
 

              
< mycontainer operation="delete">

              
 

              
The
                  server should still return  “ok�

            

          

          


          

          
Yes, that's correct in my opinion. It's a consequence of
            the NP container nature as defined in the current
            RFC6020/YANG 1.0 and bis.

          
 

          

            

              
If so I
                  think this is confusing. I think it would make more
                  sense in the latter case if the server returns “"data-missing†error.

            

          

          


          

          
This is logical if you think of NP containers as path
            prefixes, and not as objects with information content. If
            you accept that an NP container has zero bits of
            information, how would the server even know whether the
            container exists or not? Not by looking in a database, for
            sure.

          


          

          
P containers have a single bit of information, so they
            can be created, and the creation event/existence remembered
            by the server. Not so for NP-containers.

          


          

          

            

              
I
                  understand we may advise a client not do so, but since
                   RFC6020bis does not forbid this, and it is also a
                  perfectly valid <edit-config>, so I am sure
                  people will try it.

            

          

          


          

          
Yes. And it works today and is harmless.

          


          

          
It's unfortunate that the YANG 1.0 and 1.1 specs aren't
            crystal clear on the subject, but I believe the
            interpretation I and others have of NP container behavior in
            RFC 6020 is consistent, implementable and highly useful.

          


          

          
/jan

          


          

        

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Fri Jul 22 03:15:51 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34A512DF8C for ; Fri, 22 Jul 2016 03:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8zBFw6tjIDw7 for ; Fri, 22 Jul 2016 03:15:48 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B601712DF8A for ; Fri, 22 Jul 2016 03:15:47 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-7b-5791f2503f6f
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E9.26.12926.052F1975; Fri, 22 Jul 2016 12:15:45 +0200 (CEST)
Received: from [100.94.32.149] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Fri, 22 Jul 2016 12:15:44 +0200
To: Andy Bierman , Juergen Schoenwaelder , Mahesh Jethanandani , Netconf 
References: <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309417c9a@ericsson.com> <20160719134835.GB50107@elstar.local> <9609a05c-d5d4-ada1-fa90-53f798224a81@cisco.com>    <20160720063054.GA51663@elstar.local> 
From: Balazs Lengyel 
Message-ID: 
Date: Fri, 22 Jul 2016 12:15:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM2K7q27gp4nhBl//cFo8ODKL3eLqxp+M FqffrGOzmLrpNqsDi8fOWXfZPZYs+cnkseGAp0dL/0WWAJYoLpuU1JzMstQifbsErowbP6ew FXQaVZxe9ZyxgbFNsYuRk0NCwETi0M6TbBC2mMSFe+vBbCGBI4wS0xfFQNirGSVm9AqC2MIC CRIP735nBLFFBDYxSjxsT+hi5AKqmc4qseLOHBaQBJuAkcTU/vNgNq+AvcSKRd3MIDaLgKrE /5ObwRaICsRINN4+zA5RIyhxcuYTsHpOgUCJr1/XgtUzC+hLXL9znxXClpdo3jqbGeIgDYmH F/6yTmAUmIWkfRaSlllIWhYwMq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECAzeg1t+q+5g vPzG8RCjAAejEg/vAt6J4UKsiWXFlbmHGCU4mJVEeCPeA4V4UxIrq1KL8uOLSnNSiw8xSnOw KInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwBq2/ccD1QNXD3RmrJjvz3Zm6z7knb94DN7dF hR0XT4nec61SMNhg/fLBX7WMI8w7XqxXPnF+hmjVL6tLNpxTZlwrLbh7apn89imMTvHhGrM5 VieGly2peVlTsdZeNpLlJkPAI/tjcrNE1xn93mXSYmbDr/37PW9+C4uelj1rkojGfzV+6TPH lFiKMxINtZiLihMB57koq1oCAAA=
Archived-At: 
Subject: [Netconf] The problem with NP containers [was: Re: What should a server response be?]
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2016 10:15:50 -0000


  
    
  
  
    
Hello,

    Basic problem is that Netconf (and many people) consider data
    existing or not.  At least the create/delete/none operation does
    assign a meeting to the existence (or non-existence) of a data node
    even if it does not have a meaning from a configuration point of
    view. There is no such thing as not so-much-existing, no place for
    ambiguity. NP containers violate this principle.  

    
See my other mail about the proposed solution.

    

    
regards Balazs

    

    

    
On 2016-07-20 08:50, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Jul 19, 2016 at 11:30 PM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Tue,
              Jul 19, 2016 at 11:27:45PM -0700, Andy Bierman wrote:

              > On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani
              <

              > mjethanandani@gmail.com>
              wrote:

              >

              > > Based on the responses, here is what I can seem
              to summarize.

              > >

              > > 1). The current text around NP containers is not
              helpful. Balasz, do you

              > > want to write the errata? I like Juergen’s
              suggestion

              > >

              > >   "If a container does not have a "presence"
              statement and the container

              > >    has no child nodes, the NETCONF server MAY
              delete the container.”

              > >

              > > 2) Add Jan’s table with clarifications that
              Balazs has requested on the

              > > YANG wiki.

              > >

              >

              > I object to expanding the text as specified.

              > IMO this behavior favors 1 implementation choice over
              another.

              >

              

              Why?

            

            


            

            
because implementation is non-trivial regardless what
              tail-f says.

            
One can also decide to remove the text about MAY delete

            
an NP container after the last child is deleted.

            


            

            
The text about default-operation=none is in RFC 6241
              not this draft.

            
That document does not say anything about ignoring the
              error conditions

            
for "none".

            


            

            
Also, the text only affects the NETCONF
              <edit-config> operation.

            
So you want this change? Fine.  It does not apply to
              RESTCONF

            
or NETCONF <copy-config>.

            


            

            
I also strongly object to significant design changes
              being made

            
as errata.  Pull the document back into the WG to make
              these changes.

            


            

            


            

            
 

            

              

                  /js

                

            


            

            
Andy

            
 

            

                  

                  --

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

                  Phone: +49 421 200 3587         Campus Ring 1 | 28759
                  Bremen | Germany

                  Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

                

          

          

        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Fri Jul 22 07:57:15 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E8F12DB60 for ; Fri, 22 Jul 2016 07:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CQiBgJoFPRoz for ; Fri, 22 Jul 2016 07:57:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 35FBD12D612 for ; Fri, 22 Jul 2016 07:57:11 -0700 (PDT)
Received: from [10.61.204.103] (unknown [173.38.220.49]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D9851AE0398; Fri, 22 Jul 2016 16:57:09 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_00D2B020-B89C-4A93-8C18-DEA879C3D9DC"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>
Date: Fri, 22 Jul 2016 16:57:07 +0200
Message-Id: <51C4CC1B-FDA7-4074-AFCC-C46E8758B777@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericss on.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>   <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2016 14:57:14 -0000

--Apple-Mail=_00D2B020-B89C-4A93-8C18-DEA879C3D9DC
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_810FBC1E-15A0-44D3-9C67-D06E28855B96"


--Apple-Mail=_810FBC1E-15A0-44D3-9C67-D06E28855B96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> We seem to have fundamental differences whether NP-containers =
exist/don't exist or if this question is even valid.  I hope we can =
agree that as NP-containers are meaningless themselves they MUST NOT =
influence Netconf operations or model validation.
>=20
+1
> (Which is a slight violation of Netconf-6241, which we should accept.)
>=20
Balasz, could you be more specific please?
> So I propose the following errata to rfc6020bis.
>=20
> As for non-presence containers the presence of the container node with =
no child nodes is
> semantically equivalent to the absence of the container node, =
configuration operations or
> model validation should never fail due to the existence or =
non-existence of a non-presence containers. Specifically:
>=20
> - an   create operation for a non-presence container MUST =
succeed even if the container already exists.
> - an   delete operation for a non-presence container MUST =
succeed even if the container does not exist.
> - an   operation with default-operation=3Dnone MUST =
succeed even if one or more  non-presence containers do not exist.
>=20
IMO the above is a possible/reasonable clarification that will make life =
simpler for implementers and users alike. But I do find the language =
around 'creation' and 'deletion' a little counter productive, since it =
cements the basic misunderstanding that is causing folks' headache. If =
we tried to improve the explanation of what NP containers really are =
(path prefixes with no moving parts), people might find it easier to =
understand and accept the defined behavior as a natural consequence =
rather than a set of exceptional rules. See below for an attempt at =
clarifying the text.
> Separately
> - a must statement defined as direct substatement of a non-presence =
container SHALL be evaluated as part of model validation if and only if =
one or more child data nodes exist in the instance data or if there is a =
leaf or leaf-list child with a default value. As non-presence containers =
are only used for organizing the hierarchy they SHOULD NOT have any must =
substatements.
>=20
No, no, it's the other way around. Non-presence containers SHALL always =
be validated, once for every parent node they live in, exactly like P =
containers that are in the created state. Our own IETF YANG models =
depend on this fact already, and there are cases that would get really =
hairy by adding CLRs that must statements cannot/shouldn't live in NP =
containers. For example, how would you express the following without a =
must statement on the NP container? (from =
ietf-zerotouch-bootstrap-server.yang)

      container ownership-voucher {
        description
          "This container contains the Ownership Voucher that the
           device uses to ascertain the identity of its rightful
           owner, as certified by its Vendor.";

        when "../redirect-information/signature or =
../bootstrap-information/*/signature";
        must "../owner-certificate";

        uses ownership-voucher-grouping;
      }

Here's another example:

grouping ... {
  container cfm {
    container traceroute-cache {
      must "hold-time or cache-size" { ... }

How would you enforce that at least one of hold-time or cache-size =
exists without a must statement on an NP container?


So here is an attempt at explaining the NP container behavior by adding =
a few lines after the presence-container has been specified.

7.5.1.1 Non-presence containers

Containers without any presence statement inside, non-presence =
containers, are logically treated like presence containers that are =
hardwired to always exist. Any attempt to create a non-presence =
container has no effect, and is accepted without returning any error. =
Deleting a non-presence container deletes all the child nodes of the =
container, but has otherwise no effect on the container itself. No error =
is returned if it is already empty. Servers MAY choose to suppress empty =
non-presence containers in get and get-config operations for brevity.

We may want to include some sort of table comparing/contrasting the two =
as well.

/jan


--Apple-Mail=_810FBC1E-15A0-44D3-9C67-D06E28855B96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.  I hope =
we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model =
validation.
+1
 (Which is a slight
      violation of Netconf-6241, which we should accept.)
Balasz, could you be more =
specific please?

    
So I propose the following errata to =
rfc6020bis.
As for non-presence containers the presence =
of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:
- an <edit-config>  create operation for a =
non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>  delete operation for a non-presence
      container MUST succeed even if the container does not exist.  =


      - an <edit-config>  operation with =
default-operation=3Dnone
      MUST succeed even if one or more  non-presence containers do =
not
      exist. 
IMO the =
above is a possible/reasonable clarification that will make life simpler =
for implementers and users alike. But I do find the language around =
'creation' and 'deletion' a little counter productive, since it cements =
the basic misunderstanding that is causing folks' headache. If we tried =
to improve the explanation of what NP containers really are (path =
prefixes with no moving parts), people might find it easier to =
understand and accept the defined behavior as a natural consequence =
rather than a set of exceptional rules. See below for an attempt at =
clarifying the text.

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for =
organizing the hierarchy they SHOULD NOT have any must =
substatements.
No, no, it's the other =
way around. Non-presence containers SHALL always be validated, once for =
every parent node they live in, exactly like P containers that are in =
the created state. Our own IETF YANG models depend on this fact already, =
and there are cases that would get really hairy by adding CLRs that must =
statements cannot/shouldn't live in NP containers. For example, how =
would you express the following without a must statement on the NP =
container? =
(from ietf-zerotouch-bootstrap-server.yang)

      container =
ownership-voucher {
      =
  description
        =
  "This container contains the Ownership Voucher that the
           device uses to =
ascertain the identity of its rightful
    =
       owner, as certified by its Vendor.";

        when =
"../redirect-information/signature or =
../bootstrap-information/*/signature";
    =
    must "../owner-certificate";

        uses =
ownership-voucher-grouping;
      =
}

Here's another =
example:

grouping ... {
  container cfm {
    container =
traceroute-cache {
      =
must "hold-time or cache-size" { ... }

How would you enforce that at least one of =
hold-time or cache-size exists without a must statement on an NP =
container?
 

So here =
is an attempt at explaining the NP container behavior by adding a few =
lines after the presence-container has been specified.

7.5.1.1 Non-presence containers

Containers without any presence statement inside, =
non-presence containers, are logically treated like presence containers =
that are hardwired to always exist. Any attempt to create a non-presence =
container has no effect, and is accepted without returning any error. =
Deleting a non-presence container deletes all the child nodes of the =
container, but has otherwise no effect on the container itself. No error =
is returned if it is already empty. Servers MAY choose to suppress empty =
non-presence containers in get and get-config operations for =
brevity.

We may want to include some =
sort of table comparing/contrasting the two as well.

/jan

=

--Apple-Mail=_810FBC1E-15A0-44D3-9C67-D06E28855B96--

--Apple-Mail=_00D2B020-B89C-4A93-8C18-DEA879C3D9DC
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

iQEcBAEBCgAGBQJXkjRDAAoJEBSCnbqufIis9KQIALUfW68454KA7AbCE0G3CnNt
E/WfxlXZFtR8rgyP63BwL8g1tAvYMk2RF4PsVPiXXLnG60MXvRrkDnrtlMBmeg3u
Cyspotgoq39HJTnoxs8eXhrXLzoyF5Xnapp3EGCNwyIu8oocn/y+v8H/WO/3TDoy
NE/7Mk7h6+ZXQTqgRXZ/l+1ern4+i6mDtJEUenKoy0FEV00PI/WRAYv5YIgrOAF3
Hp5cieOfp1UZPiJpxRi8Zy3tVIhLy2O1agOl5SCK/9FQ6PADHbpK2TEobr1RrYSR
p1TEul3qxx9H0I7zHiH26Sa/HYhQFd0kfKJh4MKXxwc1V/7ciXaGwdKvifU0Z3s=
=k1O5
-----END PGP SIGNATURE-----

--Apple-Mail=_00D2B020-B89C-4A93-8C18-DEA879C3D9DC--


From nobody Fri Jul 22 08:15:29 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26EF12DB93 for ; Fri, 22 Jul 2016 08:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgWl6tM3mxm8 for ; Fri, 22 Jul 2016 08:15:25 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20AD12DB8F for ; Fri, 22 Jul 2016 08:15:24 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id s189so161000241vkh.1 for ; Fri, 22 Jul 2016 08:15:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RmkQq1l+KzgCw3iN9mQksrvLFRMGZ6iEbGqE/40Bi+k=; b=GgVnEc42yt66tX09IIEg4OLPVyioyqNOOccbXtxELWrx1sjEt3GC9ue3hzD6mADLXy CS5Pg6EgbhBL1Ay6EPbclpIBkRTwxi3R271MuXbTbJeGcIgT7zwZWqlpRfZ4KdoPMzxM vv0nMJJ0SPQj2KGMFiPnTRY+1Y0MP5XMpGYLxiX7LoIgYcbhMjfj5zTrVzdIP0pmllli s9mXeiord/+jaqP0hxxGBLdBNRddf39RyDJ2vjptHD6nIDjAegYzMye1bzDT+RX1f+yt 00P53Lj4R4XQVsJ7u5edFNVgIQXpYll9mkJG1LwK123kbQnuGG0lEA2plbt1yzAM3hXl MEUA==
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; bh=RmkQq1l+KzgCw3iN9mQksrvLFRMGZ6iEbGqE/40Bi+k=; b=g6K/RrsSyAugbp+0/mE6HYT7tsw7LbnWjXXdxVfyewOL5PJWTTzkoujC1QdVyN3R+E DTxhQzTFjmCHxRwGFCTzzC8uzpvdxJ1N802VPFyqeg7FlofNfheKwA37pjK/oZv103wJ XHpnbk3qZuPH1qRY15RFC6oG6nUmrwjSkyHNuLNWtEsBMIT8P4E8dYI2HMrXpZ74Mn2L 47CGJxYuOIuamH0ywnUJkocFDgtyMoyjIeF+bJehFPdeUCLIAVzlsNj0GHC2Rf4X1GmP eLhlopUv8ZlHGZzXjNiLeVBDEGwNTB2UnZqdzRbJihI8x5bBXXqThztJQCIh4+ba3dPD Ju0g==
X-Gm-Message-State: AEkoousE1TgHMWizq3mJ3DKkbVIDPYbqoqX+J4P4HK+pkgj7ci3eMs9UB9tFESTJQmya2hoX8uqV8sUBQNo+yw==
X-Received: by 10.31.233.65 with SMTP id g62mr1899358vkh.123.1469200524022; Fri, 22 Jul 2016 08:15:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Fri, 22 Jul 2016 08:15:23 -0700 (PDT)
In-Reply-To: <51C4CC1B-FDA7-4074-AFCC-C46E8758B777@tail-f.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <51C4CC1B-FDA7-4074-AFCC-C46E8758B777@tail-f.com>
From: Andy Bierman 
Date: Fri, 22 Jul 2016 08:15:23 -0700
Message-ID: 
To: Jan Lindblad 
Content-Type: multipart/alternative; boundary=94eb2c096bfa56aec705383ae7f0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jul 2016 15:15:28 -0000

--94eb2c096bfa56aec705383ae7f0
Content-Type: text/plain; charset=UTF-8

On Fri, Jul 22, 2016 at 7:57 AM, Jan Lindblad  wrote:

> We seem to have fundamental differences whether NP-containers exist/don't
> exist or if this question is even valid.  I hope we can agree that as
> NP-containers are meaningless themselves they MUST NOT influence Netconf
> operations or model validation.
>
> +1
>
>
too bad the YANG 1.1 doesn't say anything about this at all.
What it actually says is that a server MAY delete an NP container
after the last child node is deleted by an  operation.


YANG 1.1 is not backward compatible with YANG 1.1 wrt/ must-stmt.


module foo {

   container top {
      presence "";
   }

}

module bar {

   augment /foo:top {
      container two {
         must "A > 4";
         leaf A { type int32; }
      }
   }
}


YANG 1.0 there was text about an NP container always being in the schema
tree.
For an "old client" that does not know about module bar, a "create /foo:top"
operation worked fine.  But in YANG 1.1 this is completely broken because
this create will fail because the must-stmt in /foo:top/bar:two will
immediately be false.
So much for this nonsense that NP containers are invisible in the protocol.

The same result occurs if /foo:top is created via NETCONF  or
RESTCONF



Andy



> (Which is a slight violation of Netconf-6241, which we should accept.)
>
> Balasz, could you be more specific please?
>
> So I propose the following errata to rfc6020bis.
>
> As for non-presence containers the presence of the container node with no
> child nodes is
> semantically equivalent to the absence of the container node,
> configuration operations or
> model validation should never fail due to the existence or non-existence
> of a non-presence containers. Specifically:
>
> - an   create operation for a non-presence container MUST
> succeed even if the container already exists.
> - an   delete operation for a non-presence container MUST
> succeed even if the container does not exist.
> - an   operation with default-operation=none MUST succeed
> even if one or more  non-presence containers do not exist.
>
> IMO the above is a possible/reasonable clarification that will make life
> simpler for implementers and users alike. But I do find the language around
> 'creation' and 'deletion' a little counter productive, since it cements the
> basic misunderstanding that is causing folks' headache. If we tried to
> improve the explanation of what NP containers really are (path prefixes
> with no moving parts), people might find it easier to understand and accept
> the defined behavior as a natural consequence rather than a set of
> exceptional rules. See below for an attempt at clarifying the text.
>
> Separately
> - a must statement defined as direct substatement of a non-presence
> container SHALL be evaluated as part of model validation if and only if one
> or more child data nodes exist in the instance data or if there is a leaf
> or leaf-list child with a default value. As non-presence containers are
> only used for organizing the hierarchy they SHOULD NOT have any must
> substatements.
>
> No, no, it's the other way around. Non-presence containers SHALL always be
> validated, once for every parent node they live in, exactly like P
> containers that are in the created state. Our own IETF YANG models depend
> on this fact already, and there are cases that would get really hairy by
> adding CLRs that must statements cannot/shouldn't live in NP containers.
> For example, how would you express the following without a must statement
> on the NP container? (from ietf-zerotouch-bootstrap-server.yang)
>
>       container ownership-voucher {
>         description
>           "This container contains the Ownership Voucher that the
>            device uses to ascertain the identity of its rightful
>            owner, as certified by its Vendor.";
>
>         when "../redirect-information/signature or
> ../bootstrap-information/*/signature";
>         must "../owner-certificate";
>
>         uses ownership-voucher-grouping;
>       }
>
> Here's another example:
>
> grouping ... {
>   container cfm {
>     container traceroute-cache {
>       must "hold-time or cache-size" { ... }
>
> How would you enforce that at least one of hold-time or cache-size exists
> without a must statement on an NP container?
>
>
> So here is an attempt at explaining the NP container behavior by adding a
> few lines after the presence-container has been specified.
>
> 7.5.1.1 Non-presence containers
>
> Containers without any presence statement inside, non-presence containers,
> are logically treated like presence containers that are hardwired to always
> exist. Any attempt to create a non-presence container has no effect, and is
> accepted without returning any error. Deleting a non-presence container
> deletes all the child nodes of the container, but has otherwise no effect
> on the container itself. No error is returned if it is already empty.
> Servers MAY choose to suppress empty non-presence containers in get and
> get-config operations for brevity.
>
> We may want to include some sort of table comparing/contrasting the two as
> well.
>
> /jan
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--94eb2c096bfa56aec705383ae7f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jul 22, 2016 at 7:57 AM, Jan Lindblad <janl@tail-f.com> wrote:
<=
div>
We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.=C2=A0 I hope=
 we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation.
<=
div>+1


too bad the YANG 1.1 doesn't say anything about this at all.
What it actually says is that a server MAY delete an NP container<=
div>after the last child node is deleted by an <edit-config> operatio=
n.


YANG 1.1 is not backward compati=
ble with YANG 1.1 wrt/ must-stmt.


m=
odule foo {

=C2=A0 =C2=A0container top {
=C2=A0 =C2=A0 =C2=A0 presence "";
=C2=A0 =C2=A0}<=
/div>

}

module bar {

=C2=A0 =C2=A0augment /foo:top {
=C2=A0 =
=C2=A0 =C2=A0 container two {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m=
ust "A > 4";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf =
A { type int32; }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =
=C2=A0}
}

=C2=A0
YANG 1.0 ther=
e was text about an NP container always being in the schema tree.
For an "old client" that does not know about module bar, a "=
;create /foo:top"
operation worked fine.=C2=A0 But in YANG 1=
.1 this is completely broken because
this create will fail becaus=
e the must-stmt in /foo:top/bar:two will immediately be false.
So=
 much for this nonsense that NP containers are invisible in the protocol.

The same result occurs if /foo:top is created via N=
ETCONF <copy-config> or RESTCONF


<=
div>
Andy

=C2=A0
=

 (Which is a slight
      violation of Netconf-6241, which we should accept.)
Balasz, could you be more specific please?

    
So I propose the following errata to rfc6020bis.
As for no=
n-presence containers the presence of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:
- an =
<edit-config>=C2=A0 create operation for a non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>=C2=A0 delete operation for a non-presence
      container MUST succeed even if the container does not exist.=C2=A0 
      - an <edit-config>=C2=A0 operation with default-operation=3Dnon=
e
      MUST succeed even if one or more=C2=A0 non-presence containers do not
      exist. 
IMO the above is a possi=
ble/reasonable clarification that will make life simpler for implementers a=
nd users alike. But I do find the language around 'creation' and &#=
39;deletion' a little counter productive, since it cements the basic mi=
sunderstanding that is causing folks' headache. If we tried to improve =
the explanation of what NP containers really are (path prefixes with no mov=
ing parts), people might find it easier to understand and accept the define=
d behavior as a natural consequence rather than a set of exceptional rules.=
 See below for an attempt at clarifying the text.

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for organizin=
g the hierarchy they SHOULD NOT have any must substatements.
No, no, it's the other way around. Non-presence cont=
ainers SHALL always be validated, once for every parent node they live in, =
exactly like P containers that are in the created state. Our own IETF YANG =
models depend on this fact already, and there are cases that would get real=
ly hairy by adding CLRs that must statements cannot/shouldn't live in N=
P containers. For example, how would you express the following without a mu=
st statement on the NP container? (from=C2=A0ietf-zerotouch-bootstrap-serve=
r.yang)

=C2=A0 =C2=A0 =C2=A0=C2=A0container owners=
hip-voucher {
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0description
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"This container contains the Ownership V=
oucher that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device uses to =
ascertain the identity of its rightful
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0owner, as certified by its Vendor.";

=C2=A0 =C2=A0 =
=C2=A0 =C2=A0=C2=A0when "../redirect-information/signature or ../boots=
trap-information/*/signature";
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0mus=
t "../owner-certificate";

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=
=A0uses ownership-voucher-grouping;
=C2=A0 =C2=A0 =C2=A0 }
<=
div>
Here's another example:

gro=
uping ... {
=C2=A0 container cfm {
=C2=A0 =C2=A0 container traceroute=
-cache {
=C2=A0 =C2=A0 =C2=A0 must=C2=A0"hold-time or cache-size&qu=
ot; { ... }

How would you enforce that at least one of ho=
ld-time or cache-size exists without a must statement on an NP container?
=C2=A0

So here is an attempt at explainin=
g the NP container behavior by adding a few lines after the presence-contai=
ner has been specified.

7.5.1.1 Non-presence conta=
iners

Containers without any presence statement in=
side, non-presence containers, are logically treated like presence containe=
rs that are hardwired to always exist. Any attempt to create a non-presence=
 container has no effect, and is accepted without returning any error. Dele=
ting a non-presence container deletes all the child nodes of the container,=
 but has otherwise no effect on the container itself. No error is returned =
if it is already empty. Servers MAY choose to suppress empty non-presence c=
ontainers in get and get-config operations for brevity.

We may want to include some sort of table comparing/contrasting the t=
wo as well.

/jan


___________=
____________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c096bfa56aec705383ae7f0--


From nobody Mon Jul 25 04:03:48 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8F912D7AA for ; Mon, 25 Jul 2016 04:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 n-GG7yLa4Qdx for ; Mon, 25 Jul 2016 04:03:44 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C612D7A0 for ; Mon, 25 Jul 2016 04:03:44 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 73D9C1AE0398; Mon, 25 Jul 2016 13:03:41 +0200 (CEST)
To: Benoit Claise 
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com> <578CA5E7.6050906@tail-f.com>
From: Per Hedeland 
Message-ID: <5795F20C.8020308@tail-f.com>
Date: Mon, 25 Jul 2016 13:03:40 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <578CA5E7.6050906@tail-f.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2016 11:03:46 -0000

Hi,

Unfortunately my advice below, to use yanger directly instead of via
confdc for the purpose of YANG validation, was a bit premature. Path
validation for 'must' and 'when' is only done (in a tail-f-specific
plugin) when yanger is invoked with '-f fxs', which confdc does - and I
gather this validation was a major reason to use confdc in this context.

Fixing this (i.e. making yanger "core" do this validation) is on the
TODO list, but for now it is probably preferable to use confdc (or
yanger with '-f fxs'), even though it will have the drawbacks I
mentioned below.

--Per

On 2016-07-18 11:48, Per Hedeland wrote:
> On 2016-07-18 01:36, Benoit Claise wrote:
>> Hi Jason,
>>>
>>> Hi Benoit,
>>>
>>> I think your link is a bit broken below (for yangvalidator.com).
>>>
>> http://www.yangvalidator.com/
>>>
>>> Is confdc available as a standalone tool ?  I took a quick look around but didnt find it.
>>>
>> https://developer.cisco.com/site/confD/downloads/
> 
> Well, not exactly "standalone" I guess... But anyway, for the purpose of
> YANG validation, I would suggest that 'yanger' is a more appropriate
> tool than 'confdc' - 'yanger' is "An extensible YANG validator and
> converter" just like pyang, though not written in Python. confdc used to
> use pyang "under the cover", but nowadays uses yanger instead.
> 
> Using yanger directly instead of via confdc will avoid getting reports
> of tail-f-specific "errors" like "cannot compile submodules; compile the
> module instead" or "cannot compile modules with top-level choices", and
> will also avoid spending cycles on littering your file system with .fxs
> files that are of no use in this context.
> 
> When using a ConfD installation per above, 'yanger' will be in your $PATH
> just like 'confdc' - it doesn't have any actual documentation yet, but
> invoking 'yanger -h' will give a usage summary. Typically you only need
> to run 'yanger ' though.
> 
> --Per
> 
>> Regards, B.
>>
>>> Jason
>>>
>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Benoit Claise
>>> *Sent:* Saturday, July 16, 2016 14:26
>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
>>>
>>> Dear authors,
>>>
>>>
>>> Part of the IETF hackathon today, I integrated confdc , as a second YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. Reason? For example, confdc validates xpath while
>>> pyang doesn't.
>>> And confdc found an issue with your draft, which is now flagged as failing the YANG compilation.
>>> Please correct this issue.
>>> Note: you're not alone, look at the green dip today on green graph !
>>>
>>> During the hackathon today, Carl Moberg also integrated the confdc output in his www.yangalidtor.com .
>>> This might help you.
>>>
>>> Regards, Benoit
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> 


From nobody Mon Jul 25 08:50:19 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5546A12D0FC for ; Mon, 25 Jul 2016 08:50:16 -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 autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRdYW9O5pVG4 for ; Mon, 25 Jul 2016 08:50:14 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C5E12D096 for ; Mon, 25 Jul 2016 08:50:14 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id n129so203689592vke.3 for ; Mon, 25 Jul 2016 08:50: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:from:date:message-id:subject:to :cc; bh=/xQDLBP2BWFqnPqA1jkFnFlcfA6CuchI599ub/xa64A=; b=bI8EF9JdCsHSdFFEwe0YeOtgy6YB9U+iIGnMu8LKomgfiETrK2b1fGidIOkrp18V1w 4as+GiHyZX/W/VZ+ltAku/qo95u7xOg/57hvDrQ2HilZ9gPOr565CL485Rkx8vOuDaYi OWesVE9CdfB2skCRzHKGmrIRxU0gw5eB3pOxBxkdKa78jl9pI7GhcYd84f/GfoNl91uX cWTNooO6yUkA8Ny1V8KOLcKTGh2JJZjXa3ISHs+oot7yIXK1lOLKDiTjr4U1X3Hm+YFr B5vPoThbwfdMmxodDr5E9diDwh6OdkYEqdd/oXj7/n1o+/umQeSa8m7CJ+CxyjZ940/A 0JdA==
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; bh=/xQDLBP2BWFqnPqA1jkFnFlcfA6CuchI599ub/xa64A=; b=cHu5Q6l8g7Yu8oX3fM5PTKZ5zgk8qcLbqb+6pmXEz+oYdehdZuAEgIhUpqflij38XR 7D4G+fENw3dOV+aSezD2AaVGZtb3g3dSJhx28yYAj8/RrzgUOWjXWx2tEjUEagbAviyJ K5NDEKjJ2TFPpoaOCAv0Gb9bKcqCO0K1dD/80Gh1nDIq2NSl33IobwB+fm/IDQmmmWEB VEKMVeE3dJ4d/7nhivA8JnyLxIPt+ghTKv8J62fNJSe3MyH/IKmGSyUOMZh1gei3Qd7l et0TXP05cPuggWGPfnkYGyqLlQ90KJlC9RW/eTe5YxHURUMo0njoywpXT2vbeeWSWK0B dPnQ==
X-Gm-Message-State: AEkoousF4Bci812HF1EYH45zY6ryxC0c8763OX8Niij7x02qCHIGEFdxSGep91YeyMgHsDu14GAeAqs76rRUdQ==
X-Received: by 10.31.8.83 with SMTP id 80mr9036576vki.93.1469461813317; Mon, 25 Jul 2016 08:50:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.91.79 with HTTP; Mon, 25 Jul 2016 08:50:12 -0700 (PDT)
In-Reply-To: <5795F20C.8020308@tail-f.com>
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com> <578CA5E7.6050906@tail-f.com> <5795F20C.8020308@tail-f.com>
From: Reshad Rahman 
Date: Mon, 25 Jul 2016 17:50:12 +0200
Message-ID: 
To: Per Hedeland 
Content-Type: multipart/alternative; boundary=001a1145542e64d2a7053877bdba
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jul 2016 15:50:17 -0000

--001a1145542e64d2a7053877bdba
Content-Type: text/plain; charset=UTF-8

Hi,

Yes the main motivation to use confdc was to get the XPath validation which
pyang does not provide.

Regards,
Reshad.

On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland  wrote:

> Hi,
>
> Unfortunately my advice below, to use yanger directly instead of via
> confdc for the purpose of YANG validation, was a bit premature. Path
> validation for 'must' and 'when' is only done (in a tail-f-specific
> plugin) when yanger is invoked with '-f fxs', which confdc does - and I
> gather this validation was a major reason to use confdc in this context.
>
> Fixing this (i.e. making yanger "core" do this validation) is on the
> TODO list, but for now it is probably preferable to use confdc (or
> yanger with '-f fxs'), even though it will have the drawbacks I
> mentioned below.
>
> --Per
>
> On 2016-07-18 11:48, Per Hedeland wrote:
> > On 2016-07-18 01:36, Benoit Claise wrote:
> >> Hi Jason,
> >>>
> >>> Hi Benoit,
> >>>
> >>> I think your link is a bit broken below (for yangvalidator.com).
> >>>
> >> http://www.yangvalidator.com/
> >>>
> >>> Is confdc available as a standalone tool ?  I took a quick look around
> but didn t find it.
> >>>
> >> https://developer.cisco.com/site/confD/downloads/
> >
> > Well, not exactly "standalone" I guess... But anyway, for the purpose of
> > YANG validation, I would suggest that 'yanger' is a more appropriate
> > tool than 'confdc' - 'yanger' is "An extensible YANG validator and
> > converter" just like pyang, though not written in Python. confdc used to
> > use pyang "under the cover", but nowadays uses yanger instead.
> >
> > Using yanger directly instead of via confdc will avoid getting reports
> > of tail-f-specific "errors" like "cannot compile submodules; compile the
> > module instead" or "cannot compile modules with top-level choices", and
> > will also avoid spending cycles on littering your file system with .fxs
> > files that are of no use in this context.
> >
> > When using a ConfD installation per above, 'yanger' will be in your $PATH
> > just like 'confdc' - it doesn't have any actual documentation yet, but
> > invoking 'yanger -h' will give a usage summary. Typically you only need
> > to run 'yanger ' though.
> >
> > --Per
> >
> >> Regards, B.
> >>
> >>> Jason
> >>>
> >>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
> *Benoit Claise
> >>> *Sent:* Saturday, July 16, 2016 14:26
> >>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
> >>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error
> from confdc
> >>>
> >>> Dear authors,
> >>>
> >>>
> >>> Part of the IETF hackathon today, I integrated confdc , as a second
> YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html.
> Reason? For example, confdc validates xpath while
> >>> pyang doesn't.
> >>> And confdc found an issue with your draft, which is now flagged as
> failing the YANG compilation.
> >>> Please correct this issue.
> >>> Note: you're not alone, look at the green dip today on green graph <
> http://claise.be/IETFYANGPageCompilation.png>!
> >>>
> >>> During the hackathon today, Carl Moberg also integrated the confdc
> output in his www.yangalidtor.com .
> >>> This might help you.
> >>>
> >>> Regards, Benoit
> >>>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--001a1145542e64d2a7053877bdba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Yes the main motivation to=
 use confdc was to get the XPath validation which pyang does not provide.
Regards,
Reshad.
<=
br>
On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland=
 <=
per@tail-f.com> wrote:
Hi,<=
br>


Unfortunately my advice below, to use yanger directly instead of via

confdc for the purpose of YANG validation, was a bit premature. Path

validation for 'must' and 'when' is only done (in a tail-f-=
specific

plugin) when yanger is invoked with '-f fxs', which confdc does - a=
nd I

gather this validation was a major reason to use confdc in this context.


Fixing this (i.e. making yanger "core" do this validation) is on =
the

TODO list, but for now it is probably preferable to use confdc (or

yanger with '-f fxs'), even though it will have the drawbacks I

mentioned below.



--Per




On 2016-07-18 11:48, Per Hedeland wrote:

> On 2016-07-18 01:36, Benoit Claise wrote:

>> Hi Jason,

>>>

>>> Hi Benoit,

>>>

>>> I think your link is a bit broken below (for yangvalidator.com<=
/a>).

>>>

>> http://www.yangvalidator.com/

>>>

>>> Is confdc available as a standalone tool ?=C2=A0 I took a quic=
k look around but didn t find it.

>>>

>> https://developer.cisco.com/site/confD/do=
wnloads/

>

> Well, not exactly "standalone" I guess... But anyway, for th=
e purpose of

> YANG validation, I would suggest that 'yanger' is a more appro=
priate

> tool than 'confdc' - 'yanger' is "An extensible Y=
ANG validator and

> converter" just like pyang, though not written in Python. confdc =
used to

> use pyang "under the cover", but nowadays uses yanger instea=
d.

>

> Using yanger directly instead of via confdc will avoid getting reports=


> of tail-f-specific "errors" like "cannot compile submod=
ules; compile the

> module instead" or "cannot compile modules with top-level ch=
oices", and

> will also avoid spending cycles on littering your file system with .fx=
s

> files that are of no use in this context.

>

> When using a ConfD installation per above, 'yanger' will be in=
 your $PATH

> just like 'confdc' - it doesn't have any actual documentat=
ion yet, but

> invoking 'yanger -h' will give a usage summary. Typically you =
only need

> to run 'yanger <file>' though.

>

> --Per

>

>> Regards, B.

>>

>>> Jason

>>>

>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Benoit Claise

>>> *Sent:* Saturday, July 16, 2016 14:26

>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF

>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new =
error from confdc

>>>

>>> Dear authors,

>>>

>>>

>>> Part of the IETF hackathon today, I integrated confdc , as a s=
econd YANG module compiler, in http://www.claise.be=
/IETFYANGPageCompilation.html. Reason? For example, confdc validates xp=
ath while

>>> pyang doesn't.

>>> And confdc found an issue with your draft, which is now flagge=
d as failing the YANG compilation.

>>> Please correct this issue.

>>> Note: you're not alone, look at the green dip today on gre=
en graph <http://claise.be/IETFYANGPageCompilation.=
png>!

>>>

>>> During the hackathon today, Carl Moberg also integrated the co=
nfdc output in his www.yangalidtor.com <http://www.yangalidtor.com=
>.

>>> This might help you.

>>>

>>> Regards, Benoit

>>>

>>

>>

>>

>>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://www.ietf.org/mailman/listinfo/netconf<=
/a>

>>

>



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a1145542e64d2a7053877bdba--


From nobody Tue Jul 26 04:23:01 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C88912D686 for ; Tue, 26 Jul 2016 04:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zsyqN9cXDYn0 for ; Tue, 26 Jul 2016 04:22:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9B12D685 for ; Tue, 26 Jul 2016 04:22:50 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 648711AE02BC; Tue, 26 Jul 2016 13:22:49 +0200 (CEST)
To: Reshad Rahman 
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com> <578CA5E7.6050906@tail-f.com> <5795F20C.8020308@tail-f.com> 
From: Per Hedeland 
Message-ID: <57974808.5020308@tail-f.com>
Date: Tue, 26 Jul 2016 13:22:48 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 11:22:59 -0000

On 2016-07-25 17:50, Reshad Rahman wrote:
> Hi,
> 
> Yes the main motivation to use confdc was to get the XPath validation which
> pyang does not provide.

Well, hair-splitting perhaps, but yanger does do validation of the XPath
expression "as such" - but it doesn't (currently) validate that the
referenced nodes actually exist in the schema (what I referred to as
"path validation", there is probably some more correct term for it).
AFAIK an XPath expression that references such "impossible" nodes isn't
"invalid", but of course it is useful to find out that it does as part
of YANG validation.

--Per

> Regards,
> Reshad.
> 
> On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland  wrote:
> 
>> Hi,
>>
>> Unfortunately my advice below, to use yanger directly instead of via
>> confdc for the purpose of YANG validation, was a bit premature. Path
>> validation for 'must' and 'when' is only done (in a tail-f-specific
>> plugin) when yanger is invoked with '-f fxs', which confdc does - and I
>> gather this validation was a major reason to use confdc in this context.
>>
>> Fixing this (i.e. making yanger "core" do this validation) is on the
>> TODO list, but for now it is probably preferable to use confdc (or
>> yanger with '-f fxs'), even though it will have the drawbacks I
>> mentioned below.
>>
>> --Per
>>
>> On 2016-07-18 11:48, Per Hedeland wrote:
>>> On 2016-07-18 01:36, Benoit Claise wrote:
>>>> Hi Jason,
>>>>>
>>>>> Hi Benoit,
>>>>>
>>>>> I think your link is a bit broken below (for yangvalidator.com).
>>>>>
>>>> http://www.yangvalidator.com/
>>>>>
>>>>> Is confdc available as a standalone tool ?  I took a quick look around
>> but didn t find it.
>>>>>
>>>> https://developer.cisco.com/site/confD/downloads/
>>>
>>> Well, not exactly "standalone" I guess... But anyway, for the purpose of
>>> YANG validation, I would suggest that 'yanger' is a more appropriate
>>> tool than 'confdc' - 'yanger' is "An extensible YANG validator and
>>> converter" just like pyang, though not written in Python. confdc used to
>>> use pyang "under the cover", but nowadays uses yanger instead.
>>>
>>> Using yanger directly instead of via confdc will avoid getting reports
>>> of tail-f-specific "errors" like "cannot compile submodules; compile the
>>> module instead" or "cannot compile modules with top-level choices", and
>>> will also avoid spending cycles on littering your file system with .fxs
>>> files that are of no use in this context.
>>>
>>> When using a ConfD installation per above, 'yanger' will be in your $PATH
>>> just like 'confdc' - it doesn't have any actual documentation yet, but
>>> invoking 'yanger -h' will give a usage summary. Typically you only need
>>> to run 'yanger ' though.
>>>
>>> --Per
>>>
>>>> Regards, B.
>>>>
>>>>> Jason
>>>>>
>>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>> *Benoit Claise
>>>>> *Sent:* Saturday, July 16, 2016 14:26
>>>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
>>>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error
>> from confdc
>>>>>
>>>>> Dear authors,
>>>>>
>>>>>
>>>>> Part of the IETF hackathon today, I integrated confdc , as a second
>> YANG module compiler, in http://www.claise.be/IETFYANGPageCompilation.html.
>> Reason? For example, confdc validates xpath while
>>>>> pyang doesn't.
>>>>> And confdc found an issue with your draft, which is now flagged as
>> failing the YANG compilation.
>>>>> Please correct this issue.
>>>>> Note: you're not alone, look at the green dip today on green graph <
>> http://claise.be/IETFYANGPageCompilation.png>!
>>>>>
>>>>> During the hackathon today, Carl Moberg also integrated the confdc
>> output in his www.yangalidtor.com .
>>>>> This might help you.
>>>>>
>>>>> Regards, Benoit
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> 


From nobody Tue Jul 26 04:43:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8706312D678 for ; Tue, 26 Jul 2016 04:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuxDhv4EC6ct for ; Tue, 26 Jul 2016 04:43:20 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA33612D5EB for ; Tue, 26 Jul 2016 04:43:19 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id j12so7444077ywb.2 for ; Tue, 26 Jul 2016 04:43:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7o+DK5lB4p3FVSBHzIfWbSRIfjWu9IFptuda0qvDwXU=; b=LOcBDzw5FewH2MceOV0QtVBmGif4D+0LczSARU7+I7fFtYCsbZX3+4uG09pjKIQtRN c4QavN2qd2ptgHBLGNYVz9xEInGdRNcuf7RkfDF2v/lJ5TDchwKG8Ruz+eKa+uDUl+kq +hTUX6GvTtN5YQT3MMUn8K8yV2nfkbPiiYvL7F2QRxCZFw2L5k2XZbubJBGocGQKHCud CznN2WYbkzOvUr50c+cqPgK7Fmr3cJs+yZfqtavxNpqCnwynqGvCq/5M87gEbNOpA5Ht t2Re/qWohf4yhRjvYpdiCclziZ5koUQLJmxtqg+Dg1TRDQSObE1yYAB/IYBbfNUtKj76 lxhw==
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; bh=7o+DK5lB4p3FVSBHzIfWbSRIfjWu9IFptuda0qvDwXU=; b=hlcYTSqBlrUGE0H8qXSujndzW5G2pAARI0jOrGUEze3bQCbsxHfUdi2tRna7Gp+K15 HJjUKAbDYuia1Zgupr31PNM2115/14wXPpURXqJJZc5sJYeA5R5oyLFwCOlmiGr81NhN CO7IKZW0xvanAC6ftAW+4T30Wyxqo4FsNLx1J8Nl1HakVahqQAT323sTOVgtQ3v2a8ej mOE/t00uHa24EJBveANF7W4JV4Y8PwXGRAdzIE09FM5dO4FljG7lSxwksKW3qOFQvP+X f2QFVRj07H9b5YmIZ7K8xIg+0/4AkUWA5RUz4jslE5wlyuT45SLHSOfbeeQqSVRlioSG D1ng==
X-Gm-Message-State: AEkooutE9UEWDwlg7fW4itBuabC5r8Fdr6vS+dOpeuO1gkgMDWSV1Ghxi+Kra2kfBi2r6E6dMYRw35v/h8FSGg==
X-Received: by 10.176.69.210 with SMTP id u76mr8456626uau.16.1469533399097; Tue, 26 Jul 2016 04:43:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 26 Jul 2016 04:43:18 -0700 (PDT)
In-Reply-To: <57974808.5020308@tail-f.com>
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com> <578CA5E7.6050906@tail-f.com> <5795F20C.8020308@tail-f.com>  <57974808.5020308@tail-f.com>
From: Andy Bierman 
Date: Tue, 26 Jul 2016 04:43:18 -0700
Message-ID: 
To: Per Hedeland 
Content-Type: multipart/alternative; boundary=94eb2c11c3043d3c810538886866
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 11:43:22 -0000

--94eb2c11c3043d3c810538886866
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 26, 2016 at 4:22 AM, Per Hedeland  wrote:

> On 2016-07-25 17:50, Reshad Rahman wrote:
> > Hi,
> >
> > Yes the main motivation to use confdc was to get the XPath validation
> which
> > pyang does not provide.
>
> Well, hair-splitting perhaps, but yanger does do validation of the XPath
> expression "as such" - but it doesn't (currently) validate that the
> referenced nodes actually exist in the schema (what I referred to as
> "path validation", there is probably some more correct term for it).
> AFAIK an XPath expression that references such "impossible" nodes isn't
> "invalid", but of course it is useful to find out that it does as part
> of YANG validation.
>
>

By useful, you mean must or when expressions that are not always false.

Because

    #if 0
       my-YANG ...
    #endif

is rarely what they had in mind




> --Per
>

Andy


>
> > Regards,
> > Reshad.
> >
> > On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland  wrote:
> >
> >> Hi,
> >>
> >> Unfortunately my advice below, to use yanger directly instead of via
> >> confdc for the purpose of YANG validation, was a bit premature. Path
> >> validation for 'must' and 'when' is only done (in a tail-f-specific
> >> plugin) when yanger is invoked with '-f fxs', which confdc does - and I
> >> gather this validation was a major reason to use confdc in this context.
> >>
> >> Fixing this (i.e. making yanger "core" do this validation) is on the
> >> TODO list, but for now it is probably preferable to use confdc (or
> >> yanger with '-f fxs'), even though it will have the drawbacks I
> >> mentioned below.
> >>
> >> --Per
> >>
> >> On 2016-07-18 11:48, Per Hedeland wrote:
> >>> On 2016-07-18 01:36, Benoit Claise wrote:
> >>>> Hi Jason,
> >>>>>
> >>>>> Hi Benoit,
> >>>>>
> >>>>> I think your link is a bit broken below (for yangvalidator.com).
> >>>>>
> >>>> http://www.yangvalidator.com/
> >>>>>
> >>>>> Is confdc available as a standalone tool ?  I took a quick look
> around
> >> but didn t find it.
> >>>>>
> >>>> https://developer.cisco.com/site/confD/downloads/
> >>>
> >>> Well, not exactly "standalone" I guess... But anyway, for the purpose
> of
> >>> YANG validation, I would suggest that 'yanger' is a more appropriate
> >>> tool than 'confdc' - 'yanger' is "An extensible YANG validator and
> >>> converter" just like pyang, though not written in Python. confdc used
> to
> >>> use pyang "under the cover", but nowadays uses yanger instead.
> >>>
> >>> Using yanger directly instead of via confdc will avoid getting reports
> >>> of tail-f-specific "errors" like "cannot compile submodules; compile
> the
> >>> module instead" or "cannot compile modules with top-level choices", and
> >>> will also avoid spending cycles on littering your file system with .fxs
> >>> files that are of no use in this context.
> >>>
> >>> When using a ConfD installation per above, 'yanger' will be in your
> $PATH
> >>> just like 'confdc' - it doesn't have any actual documentation yet, but
> >>> invoking 'yanger -h' will give a usage summary. Typically you only need
> >>> to run 'yanger ' though.
> >>>
> >>> --Per
> >>>
> >>>> Regards, B.
> >>>>
> >>>>> Jason
> >>>>>
> >>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
> >> *Benoit Claise
> >>>>> *Sent:* Saturday, July 16, 2016 14:26
> >>>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
> >>>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error
> >> from confdc
> >>>>>
> >>>>> Dear authors,
> >>>>>
> >>>>>
> >>>>> Part of the IETF hackathon today, I integrated confdc , as a second
> >> YANG module compiler, in
> http://www.claise.be/IETFYANGPageCompilation.html.
> >> Reason? For example, confdc validates xpath while
> >>>>> pyang doesn't.
> >>>>> And confdc found an issue with your draft, which is now flagged as
> >> failing the YANG compilation.
> >>>>> Please correct this issue.
> >>>>> Note: you're not alone, look at the green dip today on green graph <
> >> http://claise.be/IETFYANGPageCompilation.png>!
> >>>>>
> >>>>> During the hackathon today, Carl Moberg also integrated the confdc
> >> output in his www.yangalidtor.com .
> >>>>> This might help you.
> >>>>>
> >>>>> Regards, Benoit
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Netconf mailing list
> >>>> Netconf@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netconf
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--94eb2c11c3043d3c810538886866
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 26, 2016 at 4:22 AM, Per Hedeland <per@tail-f.com> wrote:
On 2016-07-25 17:50, Reshad Ra=
hman wrote:

> Hi,

>

> Yes the main motivation to use confdc was to get the XPath validation =
which

> pyang does not provide.



Well, hair-splitting perhaps, but yanger does do validation of the XPath
expression "as such" - but it doesn't (currently) validate th=
at the

referenced nodes actually exist in the schema (what I referred to as

"path validation", there is probably some more correct term for i=
t).

AFAIK an XPath expression that references such "impossible" nodes=
 isn't

"invalid", but of course it is useful to find out that it does as=
 part

of YANG validation.




By useful, you mean mus=
t or when expressions that are not always false.

B=
ecause

=C2=A0 =C2=A0 #if 0
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0my-YANG ...
=C2=A0 =C2=A0 #endif

is rarely what they had in mind


<=
div>=C2=A0

--Per

Andy
=C2=A0



> Regards,

> Reshad.

>

> On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland <per@tail-f.com> wrote:

>

>> Hi,

>>

>> Unfortunately my advice below, to use yanger directly instead of v=
ia

>> confdc for the purpose of YANG validation, was a bit premature. Pa=
th

>> validation for 'must' and 'when' is only done (in =
a tail-f-specific

>> plugin) when yanger is invoked with '-f fxs', which confdc=
 does - and I

>> gather this validation was a major reason to use confdc in this co=
ntext.

>>

>> Fixing this (i.e. making yanger "core" do this validatio=
n) is on the

>> TODO list, but for now it is probably preferable to use confdc (or=


>> yanger with '-f fxs'), even though it will have the drawba=
cks I

>> mentioned below.

>>

>> --Per

>>

>> On 2016-07-18 11:48, Per Hedeland wrote:

>>> On 2016-07-18 01:36, Benoit Claise wrote:

>>>> Hi Jason,

>>>>>

>>>>> Hi Benoit,

>>>>>

>>>>> I think your link is a bit broken below (for yangvali=
dator.com).

>>>>>

>>>> http://www.yangvalidator.com/

>>>>>

>>>>> Is confdc available as a standalone tool ?=C2=A0 I too=
k a quick look around

>> but didn t find it.

>>>>>

>>>> https://developer.cisco.com/site/c=
onfD/downloads/

>>>

>>> Well, not exactly "standalone" I guess... But anyway=
, for the purpose of

>>> YANG validation, I would suggest that 'yanger' is a mo=
re appropriate

>>> tool than 'confdc' - 'yanger' is "An exte=
nsible YANG validator and

>>> converter" just like pyang, though not written in Python.=
 confdc used to

>>> use pyang "under the cover", but nowadays uses yange=
r instead.

>>>

>>> Using yanger directly instead of via confdc will avoid getting=
 reports

>>> of tail-f-specific "errors" like "cannot compil=
e submodules; compile the

>>> module instead" or "cannot compile modules with top-=
level choices", and

>>> will also avoid spending cycles on littering your file system =
with .fxs

>>> files that are of no use in this context.

>>>

>>> When using a ConfD installation per above, 'yanger' wi=
ll be in your $PATH

>>> just like 'confdc' - it doesn't have any actual do=
cumentation yet, but

>>> invoking 'yanger -h' will give a usage summary. Typica=
lly you only need

>>> to run 'yanger <file>' though.

>>>

>>> --Per

>>>

>>>> Regards, B.

>>>>

>>>>> Jason

>>>>>

>>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of

>> *Benoit Claise

>>>>> *Sent:* Saturday, July 16, 2016 14:26

>>>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF

>>>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.t=
xt: new error

>> from confdc

>>>>>

>>>>> Dear authors,

>>>>>

>>>>>

>>>>> Part of the IETF hackathon today, I integrated confdc =
, as a second

>> YANG module compiler, in http://www.claise=
.be/IETFYANGPageCompilation.html.

>> Reason? For example, confdc validates xpath while

>>>>> pyang doesn't.

>>>>> And confdc found an issue with your draft, which is no=
w flagged as

>> failing the YANG compilation.

>>>>> Please correct this issue.

>>>>> Note: you're not alone, look at the green dip toda=
y on green graph <

>> http://claise.be/IETFYANGPageCompilation.png>!

>>>>>

>>>>> During the hackathon today, Carl Moberg also integrate=
d the confdc

>> output in his www.yangalidtor.com <http://www.yangalidtor=
.com>.

>>>>> This might help you.

>>>>>

>>>>> Regards, Benoit

>>>>>

>>>>

>>>>

>>>>

>>>>

>>>> _______________________________________________

>>>> Netconf mailing list

>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/=
netconf

>>>>

>>>

>>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://www.ietf.org/mailman/listinfo/netconf<=
/a>

>>

>



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c11c3043d3c810538886866--


From nobody Tue Jul 26 05:29:16 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F312D773 for ; Tue, 26 Jul 2016 05:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8FfJ4oWG0UK4 for ; Tue, 26 Jul 2016 05:29:13 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC31D12D793 for ; Tue, 26 Jul 2016 05:29:12 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DE171AE02BC; Tue, 26 Jul 2016 14:29:11 +0200 (CEST)
To: Andy Bierman 
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com> <578CA5E7.6050906@tail-f.com> <5795F20C.8020308@tail-f.com>  <57974808.5020308@tail-f.com> 
From: Per Hedeland 
Message-ID: <57975796.2080500@tail-f.com>
Date: Tue, 26 Jul 2016 14:29:10 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 12:29:14 -0000

On 2016-07-26 13:43, Andy Bierman wrote:
> On Tue, Jul 26, 2016 at 4:22 AM, Per Hedeland  wrote:
> 
>> On 2016-07-25 17:50, Reshad Rahman wrote:
>>> Hi,
>>>
>>> Yes the main motivation to use confdc was to get the XPath validation
>> which
>>> pyang does not provide.
>>
>> Well, hair-splitting perhaps, but yanger does do validation of the XPath
>> expression "as such" - but it doesn't (currently) validate that the
>> referenced nodes actually exist in the schema (what I referred to as
>> "path validation", there is probably some more correct term for it).
>> AFAIK an XPath expression that references such "impossible" nodes isn't
>> "invalid", but of course it is useful to find out that it does as part
>> of YANG validation.
>>
>>
> 
> By useful, you mean must or when expressions that are not always false.

No, I mean that it is useful that a tool for YANG validation reports on
"invalid nodes" in a must or when expression (AFAICT what the actual
result of the XPath evaluation will be, or even if it is always true or
false, will depend on exactly how those nodes appear in the full XPath
expression - but it could of course be "always false"). But I believe it
is not necessarily a requirement on a tool that claims to do "XPath
validation" to report on such nodes.

But it was just a clarification, since I (intentionally) wrote that
yanger didn't do "path validation", and got the reply that "XPath
validation" was indeed the important thing - feel free to ignore it.

--Per

> Because
> 
>     #if 0
>        my-YANG ...
>     #endif
> 
> is rarely what they had in mind
> 
> 
> 
> 
>> --Per
>>
> 
> Andy
> 
> 
>>
>>> Regards,
>>> Reshad.
>>>
>>> On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland  wrote:
>>>
>>>> Hi,
>>>>
>>>> Unfortunately my advice below, to use yanger directly instead of via
>>>> confdc for the purpose of YANG validation, was a bit premature. Path
>>>> validation for 'must' and 'when' is only done (in a tail-f-specific
>>>> plugin) when yanger is invoked with '-f fxs', which confdc does - and I
>>>> gather this validation was a major reason to use confdc in this context.
>>>>
>>>> Fixing this (i.e. making yanger "core" do this validation) is on the
>>>> TODO list, but for now it is probably preferable to use confdc (or
>>>> yanger with '-f fxs'), even though it will have the drawbacks I
>>>> mentioned below.
>>>>
>>>> --Per
>>>>
>>>> On 2016-07-18 11:48, Per Hedeland wrote:
>>>>> On 2016-07-18 01:36, Benoit Claise wrote:
>>>>>> Hi Jason,
>>>>>>>
>>>>>>> Hi Benoit,
>>>>>>>
>>>>>>> I think your link is a bit broken below (for yangvalidator.com).
>>>>>>>
>>>>>> http://www.yangvalidator.com/
>>>>>>>
>>>>>>> Is confdc available as a standalone tool ?  I took a quick look
>> around
>>>> but didn t find it.
>>>>>>>
>>>>>> https://developer.cisco.com/site/confD/downloads/
>>>>>
>>>>> Well, not exactly "standalone" I guess... But anyway, for the purpose
>> of
>>>>> YANG validation, I would suggest that 'yanger' is a more appropriate
>>>>> tool than 'confdc' - 'yanger' is "An extensible YANG validator and
>>>>> converter" just like pyang, though not written in Python. confdc used
>> to
>>>>> use pyang "under the cover", but nowadays uses yanger instead.
>>>>>
>>>>> Using yanger directly instead of via confdc will avoid getting reports
>>>>> of tail-f-specific "errors" like "cannot compile submodules; compile
>> the
>>>>> module instead" or "cannot compile modules with top-level choices", and
>>>>> will also avoid spending cycles on littering your file system with .fxs
>>>>> files that are of no use in this context.
>>>>>
>>>>> When using a ConfD installation per above, 'yanger' will be in your
>> $PATH
>>>>> just like 'confdc' - it doesn't have any actual documentation yet, but
>>>>> invoking 'yanger -h' will give a usage summary. Typically you only need
>>>>> to run 'yanger ' though.
>>>>>
>>>>> --Per
>>>>>
>>>>>> Regards, B.
>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>>>> *Benoit Claise
>>>>>>> *Sent:* Saturday, July 16, 2016 14:26
>>>>>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
>>>>>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error
>>>> from confdc
>>>>>>>
>>>>>>> Dear authors,
>>>>>>>
>>>>>>>
>>>>>>> Part of the IETF hackathon today, I integrated confdc , as a second
>>>> YANG module compiler, in
>> http://www.claise.be/IETFYANGPageCompilation.html.
>>>> Reason? For example, confdc validates xpath while
>>>>>>> pyang doesn't.
>>>>>>> And confdc found an issue with your draft, which is now flagged as
>>>> failing the YANG compilation.
>>>>>>> Please correct this issue.
>>>>>>> Note: you're not alone, look at the green dip today on green graph <
>>>> http://claise.be/IETFYANGPageCompilation.png>!
>>>>>>>
>>>>>>> During the hackathon today, Carl Moberg also integrated the confdc
>>>> output in his www.yangalidtor.com .
>>>>>>> This might help you.
>>>>>>>
>>>>>>> Regards, Benoit
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Netconf mailing list
>>>>>> Netconf@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> 


From nobody Tue Jul 26 08:23:35 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2B112D8B3 for ; Tue, 26 Jul 2016 08:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIQpHwW6ul2E for ; Tue, 26 Jul 2016 08:23:28 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B68012DBA9 for ; Tue, 26 Jul 2016 07:49:35 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id w38so8296134qtb.0 for ; Tue, 26 Jul 2016 07:49:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/nGrgVEeG9N+pwV7WEMmyXe+hQFPnLvvFZ8h2iGZoK0=; b=LQUvkxSfdDpG7/BjZajqBaAxL7ZPC5unmo0R+jjlXpekJhIViBkikVJoSSq4QNBrs6 LlQO1n3PB6rB5y8M2rsgKmDez6k1O61FqH6InTOf/esQ7NLlS2W2Y7TKuB/iJCLgNnZG BnG//SUkqXQWzdBRmxAojO+uXLDcOh32OoCaaSUvg3+vG2GUiI6WIf2HESGcddk9p1Su u6qei3LR7lCQb5MJsbqQXxToIiCWH38mB+KS+2/71cEmEqD2CHgiiFGrTCHVUPyqRSbR 1YXUcyttD7TIZUT63+eqUCaPIwYNxl6gDGxT2fWn1n6i1Z/pLMo8V4W/WZ9m4LoddMuT 9D1Q==
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; bh=/nGrgVEeG9N+pwV7WEMmyXe+hQFPnLvvFZ8h2iGZoK0=; b=WWav/ngD4WiQ/uBlj2wKBzmHntOVOxc1Kcb0QNUQfmFO4BJI6pWvzoFT2LYlQSecMv DK5pIv9CPw4ryOdUTT/lqkfqG335/nHwdOZvrgq5ya4JGc2Yh7hFrJzJ4nf98cCEQxa/ bmXKBDeqfBRIfFSLDdVGmAPa1g3cmX9CwMuCP51L1ZPoa+kZIylMVMXGoB48tE4Sj1OI LIFihGjJFln6r3BJaqio+5sbFqM7di0sebFo69OR3IFrn2YewZG3LpdMSwIOm3YMV2Sa 9mPXUnD6OFEEm6ZoZav59X2gWFFvLGLZqnzgCQRA9zLt449xMLumnzsT1Sm878A1qfT7 vWJw==
X-Gm-Message-State: AEkoouvK63xhW/VesqPc5bE0N/DFFtfZtpmiHmLBSFvN2ZGgFcB4vrfH4dmaHL7dlK/41kCa/Ku+zThY7eAK6w==
X-Received: by 10.159.36.205 with SMTP id 71mr10460987uar.121.1469544574342; Tue, 26 Jul 2016 07:49:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 26 Jul 2016 07:49:33 -0700 (PDT)
In-Reply-To: <57975796.2080500@tail-f.com>
References:   <6d58d4f9-4dbf-a2d3-850a-1efdd7cb7b2a@cisco.com> <578CA5E7.6050906@tail-f.com> <5795F20C.8020308@tail-f.com>  <57974808.5020308@tail-f.com>  <57975796.2080500@tail-f.com>
From: Andy Bierman 
Date: Tue, 26 Jul 2016 07:49:33 -0700
Message-ID: 
To: Per Hedeland 
Content-Type: multipart/alternative; boundary=001a113e5dde5621e105388b0238
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error from confdc
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 15:23:33 -0000

--001a113e5dde5621e105388b0238
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 26, 2016 at 5:29 AM, Per Hedeland  wrote:

> On 2016-07-26 13:43, Andy Bierman wrote:
> > On Tue, Jul 26, 2016 at 4:22 AM, Per Hedeland  wrote:
> >
> >> On 2016-07-25 17:50, Reshad Rahman wrote:
> >>> Hi,
> >>>
> >>> Yes the main motivation to use confdc was to get the XPath validation
> >> which
> >>> pyang does not provide.
> >>
> >> Well, hair-splitting perhaps, but yanger does do validation of the XPath
> >> expression "as such" - but it doesn't (currently) validate that the
> >> referenced nodes actually exist in the schema (what I referred to as
> >> "path validation", there is probably some more correct term for it).
> >> AFAIK an XPath expression that references such "impossible" nodes isn't
> >> "invalid", but of course it is useful to find out that it does as part
> >> of YANG validation.
> >>
> >>
> >
> > By useful, you mean must or when expressions that are not always false.
>
> No, I mean that it is useful that a tool for YANG validation reports on
> "invalid nodes" in a must or when expression (AFAICT what the actual
> result of the XPath evaluation will be, or even if it is always true or
> false, will depend on exactly how those nodes appear in the full XPath
> expression - but it could of course be "always false"). But I believe it
> is not necessarily a requirement on a tool that claims to do "XPath
> validation" to report on such nodes.
>
> But it was just a clarification, since I (intentionally) wrote that
> yanger didn't do "path validation", and got the reply that "XPath
> validation" was indeed the important thing - feel free to ignore it.
>
>
Yes, you are more precise.
I would not ignore XPath validation.
I have not found any use-cases for explicitly stated node identifiers
that do not match any known YANG schema nodes in that context.
Valid XPath and correct XPath are not the same thing. (Just like source
code.)


--Per
>
>
Andy


> > Because
> >
> >     #if 0
> >        my-YANG ...
> >     #endif
> >
> > is rarely what they had in mind
> >
> >
> >
> >
> >> --Per
> >>
> >
> > Andy
> >
> >
> >>
> >>> Regards,
> >>> Reshad.
> >>>
> >>> On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Unfortunately my advice below, to use yanger directly instead of via
> >>>> confdc for the purpose of YANG validation, was a bit premature. Path
> >>>> validation for 'must' and 'when' is only done (in a tail-f-specific
> >>>> plugin) when yanger is invoked with '-f fxs', which confdc does - and
> I
> >>>> gather this validation was a major reason to use confdc in this
> context.
> >>>>
> >>>> Fixing this (i.e. making yanger "core" do this validation) is on the
> >>>> TODO list, but for now it is probably preferable to use confdc (or
> >>>> yanger with '-f fxs'), even though it will have the drawbacks I
> >>>> mentioned below.
> >>>>
> >>>> --Per
> >>>>
> >>>> On 2016-07-18 11:48, Per Hedeland wrote:
> >>>>> On 2016-07-18 01:36, Benoit Claise wrote:
> >>>>>> Hi Jason,
> >>>>>>>
> >>>>>>> Hi Benoit,
> >>>>>>>
> >>>>>>> I think your link is a bit broken below (for yangvalidator.com).
> >>>>>>>
> >>>>>> http://www.yangvalidator.com/
> >>>>>>>
> >>>>>>> Is confdc available as a standalone tool ?  I took a quick look
> >> around
> >>>> but didn t find it.
> >>>>>>>
> >>>>>> https://developer.cisco.com/site/confD/downloads/
> >>>>>
> >>>>> Well, not exactly "standalone" I guess... But anyway, for the purpose
> >> of
> >>>>> YANG validation, I would suggest that 'yanger' is a more appropriate
> >>>>> tool than 'confdc' - 'yanger' is "An extensible YANG validator and
> >>>>> converter" just like pyang, though not written in Python. confdc used
> >> to
> >>>>> use pyang "under the cover", but nowadays uses yanger instead.
> >>>>>
> >>>>> Using yanger directly instead of via confdc will avoid getting
> reports
> >>>>> of tail-f-specific "errors" like "cannot compile submodules; compile
> >> the
> >>>>> module instead" or "cannot compile modules with top-level choices",
> and
> >>>>> will also avoid spending cycles on littering your file system with
> .fxs
> >>>>> files that are of no use in this context.
> >>>>>
> >>>>> When using a ConfD installation per above, 'yanger' will be in your
> >> $PATH
> >>>>> just like 'confdc' - it doesn't have any actual documentation yet,
> but
> >>>>> invoking 'yanger -h' will give a usage summary. Typically you only
> need
> >>>>> to run 'yanger ' though.
> >>>>>
> >>>>> --Per
> >>>>>
> >>>>>> Regards, B.
> >>>>>>
> >>>>>>> Jason
> >>>>>>>
> >>>>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
> >>>> *Benoit Claise
> >>>>>>> *Sent:* Saturday, July 16, 2016 14:26
> >>>>>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF
> >>>>>>> *Subject:* [Netconf] draft-ietf-netconf-zerotouch-09.txt: new error
> >>>> from confdc
> >>>>>>>
> >>>>>>> Dear authors,
> >>>>>>>
> >>>>>>>
> >>>>>>> Part of the IETF hackathon today, I integrated confdc , as a second
> >>>> YANG module compiler, in
> >> http://www.claise.be/IETFYANGPageCompilation.html.
> >>>> Reason? For example, confdc validates xpath while
> >>>>>>> pyang doesn't.
> >>>>>>> And confdc found an issue with your draft, which is now flagged as
> >>>> failing the YANG compilation.
> >>>>>>> Please correct this issue.
> >>>>>>> Note: you're not alone, look at the green dip today on green graph
> <
> >>>> http://claise.be/IETFYANGPageCompilation.png>!
> >>>>>>>
> >>>>>>> During the hackathon today, Carl Moberg also integrated the confdc
> >>>> output in his www.yangalidtor.com .
> >>>>>>> This might help you.
> >>>>>>>
> >>>>>>> Regards, Benoit
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Netconf mailing list
> >>>>>> Netconf@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/netconf
> >>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> Netconf mailing list
> >>>> Netconf@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netconf
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >
>
>

--001a113e5dde5621e105388b0238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 26, 2016 at 5:29 AM, Per Hedeland <per@tail-f.com> wrote:
On 2016-07-26 13:43, Andy Bier=
man wrote:

> On Tue, Jul 26, 2016 at 4:22 AM, Per Hedeland <per@tail-f.com> wrote:

>

>> On 2016-07-25 17:50, Reshad Rahman wrote:

>>> Hi,

>>>

>>> Yes the main motivation to use confdc was to get the XPath val=
idation

>> which

>>> pyang does not provide.

>>

>> Well, hair-splitting perhaps, but yanger does do validation of the=
 XPath

>> expression "as such" - but it doesn't (currently) va=
lidate that the

>> referenced nodes actually exist in the schema (what I referred to =
as

>> "path validation", there is probably some more correct t=
erm for it).

>> AFAIK an XPath expression that references such "impossible&qu=
ot; nodes isn't

>> "invalid", but of course it is useful to find out that i=
t does as part

>> of YANG validation.

>>

>>

>

> By useful, you mean must or when expressions that are not always false=
.



No, I mean that it is useful that a tool for YANG validation reports on

"invalid nodes" in a must or when expression (AFAICT what the act=
ual

result of the XPath evaluation will be, or even if it is always true or

false, will depend on exactly how those nodes appear in the full XPath

expression - but it could of course be "always false"). But I bel=
ieve it

is not necessarily a requirement on a tool that claims to do "XPath
validation" to report on such nodes.



But it was just a clarification, since I (intentionally) wrote that

yanger didn't do "path validation", and got the reply that &q=
uot;XPath

validation" was indeed the important thing - feel free to ignore it.


Yes, you are more precise.
I=
 would not ignore XPath validation.
I have not found any use-case=
s for explicitly stated node identifiers
that do not match any kn=
own YANG schema nodes in that context.
Valid XPath and correct XP=
ath are not the same thing. (Just like source code.)



--Per



Andy
=C2=A0

> Because

>

>=C2=A0 =C2=A0 =C2=A0#if 0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 my-YANG ...

>=C2=A0 =C2=A0 =C2=A0#endif

>

> is rarely what they had in mind

>

>

>

>

>> --Per

>>

>

> Andy

>

>

>>

>>> Regards,

>>> Reshad.

>>>

>>> On Mon, Jul 25, 2016 at 1:03 PM, Per Hedeland <per@tail-f.com> wrote:

>>>

>>>> Hi,

>>>>

>>>> Unfortunately my advice below, to use yanger directly inst=
ead of via

>>>> confdc for the purpose of YANG validation, was a bit prema=
ture. Path

>>>> validation for 'must' and 'when' is only d=
one (in a tail-f-specific

>>>> plugin) when yanger is invoked with '-f fxs', whic=
h confdc does - and I

>>>> gather this validation was a major reason to use confdc in=
 this context.

>>>>

>>>> Fixing this (i.e. making yanger "core" do this v=
alidation) is on the

>>>> TODO list, but for now it is probably preferable to use co=
nfdc (or

>>>> yanger with '-f fxs'), even though it will have th=
e drawbacks I

>>>> mentioned below.

>>>>

>>>> --Per

>>>>

>>>> On 2016-07-18 11:48, Per Hedeland wrote:

>>>>> On 2016-07-18 01:36, Benoit Claise wrote:

>>>>>> Hi Jason,

>>>>>>>

>>>>>>> Hi Benoit,

>>>>>>>

>>>>>>> I think your link is a bit broken below (for <=
a href=3D"http://yangvalidator.com" rel=3D"noreferrer" target=3D"_blank">ya=
ngvalidator.com).

>>>>>>>

>>>>>> http://www.yangvalidator.com/

>>>>>>>

>>>>>>> Is confdc available as a standalone tool ?=C2=
=A0 I took a quick look

>> around

>>>> but didn t find it.

>>>>>>>

>>>>>> https://developer.cisco.co=
m/site/confD/downloads/

>>>>>

>>>>> Well, not exactly "standalone" I guess... Bu=
t anyway, for the purpose

>> of

>>>>> YANG validation, I would suggest that 'yanger'=
 is a more appropriate

>>>>> tool than 'confdc' - 'yanger' is "=
;An extensible YANG validator and

>>>>> converter" just like pyang, though not written in=
 Python. confdc used

>> to

>>>>> use pyang "under the cover", but nowadays us=
es yanger instead.

>>>>>

>>>>> Using yanger directly instead of via confdc will avoid=
 getting reports

>>>>> of tail-f-specific "errors" like "canno=
t compile submodules; compile

>> the

>>>>> module instead" or "cannot compile modules w=
ith top-level choices", and

>>>>> will also avoid spending cycles on littering your file=
 system with .fxs

>>>>> files that are of no use in this context.

>>>>>

>>>>> When using a ConfD installation per above, 'yanger=
' will be in your

>> $PATH

>>>>> just like 'confdc' - it doesn't have any a=
ctual documentation yet, but

>>>>> invoking 'yanger -h' will give a usage summary=
. Typically you only need

>>>>> to run 'yanger <file>' though.

>>>>>

>>>>> --Per

>>>>>

>>>>>> Regards, B.

>>>>>>

>>>>>>> Jason

>>>>>>>

>>>>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of

>>>> *Benoit Claise

>>>>>>> *Sent:* Saturday, July 16, 2016 14:26

>>>>>>> *To:* draft-ietf-netconf-zerotouch@ietf.org; NETCONF

>>>>>>> *Subject:* [Netconf] draft-ietf-netconf-zeroto=
uch-09.txt: new error

>>>> from confdc

>>>>>>>

>>>>>>> Dear authors,

>>>>>>>

>>>>>>>

>>>>>>> Part of the IETF hackathon today, I integrated=
 confdc , as a second

>>>> YANG module compiler, in

>> http://www.claise.be/IETFYANGPageCompilat=
ion.html.

>>>> Reason? For example, confdc validates xpath while

>>>>>>> pyang doesn't.

>>>>>>> And confdc found an issue with your draft, whi=
ch is now flagged as

>>>> failing the YANG compilation.

>>>>>>> Please correct this issue.

>>>>>>> Note: you're not alone, look at the green =
dip today on green graph <

>>>> http://claise.be/IETFYANGPageCompilatio=
n.png>!

>>>>>>>

>>>>>>> During the hackathon today, Carl Moberg also i=
ntegrated the confdc

>>>> output in his www.yangalidtor.com <http://www.y=
angalidtor.com>.

>>>>>>> This might help you.

>>>>>>>

>>>>>>> Regards, Benoit

>>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>> _______________________________________________
>>>>>> Netconf mailing list

>>>>>> Netconf@ietf.o=
rg

>>>>>> https://www.ietf.org/mailman/l=
istinfo/netconf

>>>>>>

>>>>>

>>>>

>>>> _______________________________________________

>>>> Netconf mailing list

>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/=
netconf

>>>>

>>>

>>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://www.ietf.org/mailman/listinfo/netconf<=
/a>

>>

>







--001a113e5dde5621e105388b0238--


From nobody Tue Jul 26 09:03:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F112D093 for ; Tue, 26 Jul 2016 09:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hn86G-6z2AL5 for ; Tue, 26 Jul 2016 09:02:51 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCFB12B017 for ; Tue, 26 Jul 2016 08:47:49 -0700 (PDT)
X-AuditID: c1b4fb3a-de6539800000109f-9a-57978623cbf3
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by  (Symantec Mail Security) with SMTP id C3.C9.04255.32687975; Tue, 26 Jul 2016 17:47:47 +0200 (CEST)
Received: from [159.107.198.30] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.301.0; Tue, 26 Jul 2016 17:47:30 +0200
To: Jan Lindblad 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>    <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <2d0acfdd-f340-db62-a2f7-628309 417c9a@ericss on.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <51C4CC1B-FDA7-4074-AFCC-C46E8758B777@tail-f.com>
From: Balazs Lengyel 
Message-ID: <5c62b19b-2145-8f69-c020-f84355319c9e@ericsson.com>
Date: Tue, 26 Jul 2016 17:47:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <51C4CC1B-FDA7-4074-AFCC-C46E8758B777@tail-f.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2J7oK5y2/Rwg5NvlCz+z+pjtJi66Tar xbdNf5gdmD2WLPnJ5PFwSQeLx8Zfi1kCmKO4bFJSczLLUov07RK4Mn5vPspY8D2govnpb5YG xt1mXYycHBICJhI/lrxj7WLk4hASWM8ocfvrD2YIZw2jxKkt39hBqoQFwiXePl3DBmKLCChJ nGhth+q4yi7x5d8hsASzgIPEnA8/wRrYBIwkpvafZwGxeQXsJea/mgRkc3CwCKhK3FmQC2KK CsRIrO9LgKgQlDg58wlYNaeAnUTTjoesEBP1Ja7fuQ9ly0s0b53NDGILCWhIPLzwl3UCo8As JO2zkLTMQtKygJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgqB7c8ttqB+PB546HGAU4 GJV4eBcETwsXYk0sK67MPcQowcGsJMI7tWV6uBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK 4UIC6YklqdmpqQWpRTBZJg5OqQbG8DN3O/deffr72VehOr30k8d6ys8cPyKZ/vNK9vEp3iYr Nzbee62yOIb5kqHQf6k1oZV/krO1Sr1+vZr19tqBV+e6qgM2Pjxc2v3/5mmp3467uGPi17B6 srNunu5hwH7boMjx8qvKDXwrvHm/T/58SWL1LOMEk3Oz9ouskFGVn7+wcNJhyZ69zUosxRmJ hlrMRcWJAIUTl8tRAgAA
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 16:02:55 -0000


  
    
  
  
    
Hello.

    
Based on your input here is my second attempt at the errata text.
      I tried to go for the minimum of changes. See detailed comments below! 

    

    7.5.8.  NETCONF <edit-config> Operations - changes 

    
- If the operation is "create", the node is created if it does
      not  exist.  If the node is 

      a presence container and it already exists, a "data-exists" error
      is returned. If the node is 

      a non-presence container and it already exists, the operation
      succeeds but has no effect. 

    

    
- If the operation is "delete", the node is deleted if it exists.
      If the node is 

      a presence container and it does not exist, a "data-missing" error
      is returned. If the node is 

      a non-presence container and it does not exist, the operation
      succeeds but has no effect. 

    

    
- if the default-operation is "none" the operation MUST NOT fail
      because one or more non-presence containers do not exist. 

    

    
Balazs

    

    

    
On 2016-07-22 16:57, Jan Lindblad
      wrote:

    

    

      

        
So I propose the following errata to rfc6020bis.
          

            

              

                
As for non-presence containers the presence
                  of the container node with no child nodes is 

                  semantically equivalent to the absence of the
                  container node, configuration operations or 

                  model validation should never fail due to the
                  existence or non-existence of a non-presence
                  containers. Specifically:

                
- an <edit-config>  create operation
                  for a non-presence container MUST succeed even if the
                  container already exists. 

                  - an <edit-config>  delete operation for a
                  non-presence container MUST succeed even if the
                  container does not exist.  

                  - an <edit-config>  operation with
                  default-operation=none MUST succeed even if one or
                  more  non-presence containers do not exist. 

                

              

            

          

          
IMO the above is a possible/reasonable clarification that
            will make life simpler for implementers and users alike. But
            I do find the language around 'creation' and 'deletion' a
            little counter productive, since it cements the basic
            misunderstanding that is causing folks' headache. If we
            tried to improve the explanation of what NP containers
            really are (path prefixes with no moving parts), people
            might find it easier to understand and accept the defined
            behavior as a natural consequence rather than a set of
            exceptional rules. See below for an attempt at clarifying
            the text.

        

      

    

    BALAZS: The point is we do not agree on
        this. According to 

      https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-3
        a container is a data node. 

      "container: An interior data node that exists ..."  That
        clearly states that a container _exists_.  

        We never defined the concept of a "path prefix" or this
        not-really-existing-data-node. . IMHO that is a Tailf concept
        not a rfc6020 concept.

      https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.5.1
        states:

      "YANG supports two styles of containers, those that exist
        only for organizing the hierarchy of data nodes, ..."

      So speaking about existence of containers is clearly
        in-line with the RFC6020

    

      

        

          

            

              

                
 

                
Separately

                  - a must statement defined as direct substatement of a
                  non-presence container SHALL be evaluated as part of
                  model validation if and only if one or more child data
                  nodes exist in the instance data or if there is a leaf
                  or leaf-list child with a default value. As
                  non-presence containers are only used for organizing
                  the hierarchy they SHOULD NOT have any must
                  substatements.

              

            

          

          
No, no, it's the other way around. Non-presence
            containers SHALL always be validated, once for every parent
            node they live in, exactly like P containers that are in the
            created state. Our own IETF YANG models depend on this fact
            already, and there are cases that would get really hairy by
            adding CLRs that must statements cannot/shouldn't live in NP
            containers. For example, how would you express the following
            without a must statement on the NP container?
            (from ietf-zerotouch-bootstrap-server.yang)

        

      

    

    BALAZS: OK, I see RFC6020bis already states
        this, just you have to look up a number of different chapters to
        find this.

    

      

        

          


          

          
      container ownership-voucher {

                    description

                      "This container contains the Ownership Voucher
            that the

                       device uses to ascertain the identity of its
            rightful

                       owner, as certified by its Vendor.";

            

                    when "../redirect-information/signature or
            ../bootstrap-information/*/signature";

                    must "../owner-certificate";

            

                    uses ownership-voucher-grouping;

          
      }

          


          

          
Here's another example:

          


          

          
grouping ... {

              container cfm {

                container traceroute-cache {

                  must "hold-time or cache-size" { ... }

            

          

          
How would you enforce that at least one of hold-time or
            cache-size exists without a must statement on an NP
            container?

          
 

          


          

          
So here is an attempt at explaining the NP container
            behavior by adding a few lines after the presence-container
            has been specified.

          


          

          
7.5.1.1 Non-presence containers

          


          

          
Containers without any presence statement inside,
            non-presence containers, are logically treated like presence
            containers that are hardwired to always exist. Any attempt
            to create a non-presence container has no effect, and is
            accepted without returning any error. Deleting a
            non-presence container deletes all the child nodes of the
            container, but has otherwise no effect on the container
            itself. No error is returned if it is already empty. Servers
            MAY choose to suppress empty non-presence containers in get
            and get-config operations for brevity.

        

      

    

    BALAZS: The first and second sentence
        contradict each other. If the NP-container exists a create
        netconf operation should to fail.

    

      

        

          


          

          
We may want to include some sort of table
            comparing/contrasting the two as well.

          


          

          
/jan

          


          

        

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Jul 26 13:38:44 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA5D12D941 for ; Tue, 26 Jul 2016 13:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHfDp3DWmusT for ; Tue, 26 Jul 2016 13:38:41 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20132.outbound.protection.outlook.com [40.107.2.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8654412D0BA for ; Tue, 26 Jul 2016 13:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HjYC+Kp7Xj/2tQ6wKIKSKvmZdVapP/h09ujASz7hnU8=; b=gzT32DV6ftlV4GLufVlgKyHNFLAYJl7WDS17f+DFgWEGv4ccSsgNZMN7k47YBrI51lL2vwVACjCmi04NqrdrPIBDwaYmb7MP6vDWBaRifJBMWAmCRCZvHYLNxBfq6huAbr1diEU43aS10rqtOcf0qt0nGtFnv5ZaU1kf893ksNU=
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2860.eurprd07.prod.outlook.com (10.168.91.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 26 Jul 2016 20:38:38 +0000
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0544.019; Tue, 26 Jul 2016 20:38:37 +0000
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: Netconf 
Thread-Topic: Draft Minutes of IETF 96 NETCONF Session 
Thread-Index: AdHnfaoyUKFRoqnyTEipXWBf+Wa7/w==
Date: Tue, 26 Jul 2016 20:38:37 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; 
x-originating-ip: [62.159.77.186]
x-ms-office365-filtering-correlation-id: 1a65a79a-7c47-4e9c-f56a-08d3b594d267
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2860; 6:BUrFBeeGZBC0g53OPf3S3DFCeOVWnCa08hv0lAtvLS9wzS1fwrM6zQ/Yxa5MV1tHSQyGh3kICUUHmxBo/rMj6WTMT+Hz5VWEcOyXgEs3HEbclDb2zXtyL4CVEgZYICgqu669QtAYcgflRP90gR1ceKoN9M0F6lnFv8TKfXFVDYPm7SGSbAUy33BEgF2H0KNEuUIGN+jL+Vhm/oxwfgFo9ZzeH3F2gKqsfQcSVjhnqBtj4maNCH7TmrL7QtRi65CGUsniRSQ7Esc7L6h6DD0MpCM98mbR4vz0x/qCLM+vMfXaFZPROfWgm784DB0OaGmJQtz57tcUL6MLXAVEA/1q2w==; 5:rpptRB9vlTYy6RjY2JOpBdswG4f4OIcry4dD3Oid7LROmlqogCZafLjxjWM/Rpq7bmHh1T6anky4q0TK+BWDcWPeOn30FBxg1Z6NgIa5wiqFgFLD1vsQbUzW6xZuj6mFkTCEnWrQAednm1aij39bSg==; 24:PFr8F++h9xhlYJqLb3si2klir7FTn8HQYSbYRCJpUN4BSHHqEXfocE91MC8y8rAT9ooYiELKXD1FtG3NVSeXAZnjNifugY0h1jPbZfM161A=; 7:XoP17OP550NWob1AqF04SG3Vo7xhwYqRSxhPqO1KC1RUKGze00pgnyLytZq67FVeRYM1Ql5HEmAXRcdC1GwPMFnY7aPZbgBWFxaNEj/jwVAhezHRgDa7cjSM8up2UpBbX71T579R8az7eNdPXlhdTx95dIhHvdHPUelwjCr5SLG0WAKfzHUKXw/tOmIwkPNOjFsuNkvUrMXvtYdFKTkbTmcE5vc/IgrygPxmHS6JpNkax3x6nDt0SF2E6Tw1mjxc
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2860;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);  SRVR:HE1PR0701MB2860; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2860; 
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(19580395003)(107886002)(68736007)(15975445007)(110136002)(77096005)(102836003)(2900100001)(6116002)(97736004)(586003)(3846002)(33656002)(7696003)(5003600100003)(7736002)(87936001)(86362001)(10400500002)(92566002)(5002640100001)(3660700001)(3280700002)(450100001)(101416001)(54356999)(50986999)(9686002)(106356001)(74316002)(8936002)(189998001)(81156014)(229853001)(105586002)(81166006)(122556002)(66066001)(2906002)(7846002)(305945005)(76576001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2860; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2859F0D3B98BDAC1EBC823CB910E0HE1PR0701MB2859_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 20:38:37.6425 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2860
Archived-At: 
Subject: [Netconf] Draft Minutes of IETF 96 NETCONF Session
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jul 2016 20:38:44 -0000

--_000_HE1PR0701MB2859F0D3B98BDAC1EBC823CB910E0HE1PR0701MB2859_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

below are the draft minutes of the NETCONF session in IETF 96 meeting.

https://www.ietf.org/proceedings/96/minutes/minutes-96-netconf

Please send a note to the co-chairs by August 2nd EOB, if you have request =
any changes.

Mehmet & Mahesh



--_000_HE1PR0701MB2859F0D3B98BDAC1EBC823CB910E0HE1PR0701MB2859_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear NETCONF WG,


 


below are the draft minutes of the NETCONF ses=
sion in IETF 96 meeting.


 



 


Please send a note to the co-chairs by August =
2nd EOB, if you have request any changes.


 


Mehmet & Mahesh


 


 





--_000_HE1PR0701MB2859F0D3B98BDAC1EBC823CB910E0HE1PR0701MB2859_--


From nobody Wed Jul 27 20:49:20 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5712D1E0 for ; Wed, 27 Jul 2016 20:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnG1cHynpgm8 for ; Wed, 27 Jul 2016 20:49:17 -0700 (PDT)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F9012D1D2 for ; Wed, 27 Jul 2016 20:49:16 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id s189so23426332vkh.1 for ; Wed, 27 Jul 2016 20:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YOr5gZufwGcGDIR6hT/BdfEVdVQ/OA6V+NfGJbLjV7o=; b=fPGn1lVcrmqDcf5ATUcoylfr2fbzxdTU364o2bI+WaXRJinPRDnMoOaOImBgeH9c++ M+cDvZbKWGFY10XbpnCiG0NS7uqku8JEBqGqcoI3YNkH+nKAalorp9x66fJB0A2cprIN XYnzR1w5BHAFpyp9SRuMb5ybgAyQrJ4Mp2KAUXSDNtyoLzfy2CEfAD6o2gWdt+NsBNCD BdnfVbErR7cz8tfn6TmP9MbMZE/N2WBAJLG3gb1g/jLXAOHE1I731r+pZf9ny30t4Bz0 cZi+9BVJCvL/8FFpyltszpgrn+bJBK6TCilvF0ooJQWpfJKT3apwmBaWR4K9skFx03L6 VihA==
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; bh=YOr5gZufwGcGDIR6hT/BdfEVdVQ/OA6V+NfGJbLjV7o=; b=biISxLYgvk+19kiMNpttHDwrg8RgzGVFyLSojOPmbcDEd98EX4SbJUsmXdwqzLUH2Q GIJl6s1pAGiElN+7ENTo2fGSxlX2H/WcDe0P5PalO3hm1XT5LxukF9ar38RVPJFRz9M1 22CfSZWOHKqQ528pVazMydpYiCxRbrdzKkURnGKS+8L5kfZPSXDh5k9J4fHIOfJhjWUn 4/4ZQ5bIGg98M4HcmVoeyBgDvU6lcdRmaBVgKvoxuZ7zzfFuPs1lo3prWzGdzbP8Xje1 4H/tkH7i1TB3+ZO2ZaSvdFowmKPkgyjQKDvpZownuI2l/dH1KJnYNq1K82JQCFbtMtXG 2HcQ==
X-Gm-Message-State: AEkooutvVaoDDQT9mnpuJpLq1Hc9QvkBu5Fd3rKoHtSnyAvntCCKc+wtQ3QCj48/sEMz49tYPT/19FAcl715zg==
X-Received: by 10.31.244.69 with SMTP id s66mr5152138vkh.121.1469677755775; Wed, 27 Jul 2016 20:49:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 27 Jul 2016 20:49:14 -0700 (PDT)
In-Reply-To: 
References: 
From: Andy Bierman 
Date: Wed, 27 Jul 2016 20:49:14 -0700
Message-ID: 
To: "Steve Truong (struong)" 
Content-Type: multipart/alternative; boundary=94eb2c125e189154e80538aa0482
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] Comments on draft-ietf-netconf-restconf-15 -- 3.4.1.1. Timestamp
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 03:49:18 -0000

--94eb2c125e189154e80538aa0482
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I am working on edits, but I don't see any changes here...


On Mon, Jul 11, 2016 at 10:06 AM, Steve Truong (struong) 
wrote:

>    If the RESTCONF server is colocated with a NETCONF server, then the
>
>    last-modified timestamp MUST represent the "running" datastore.
>
>
>
> If the =E2=80=9Crunning=E2=80=9D datastore can also be accessed and chang=
ed by other
> servers such as CLI, SNMP, =E2=80=A6 how would the timestamp be reported?
>
>
>


The timestamp is reported the same way no matter why the datastore changed.
The sentence does not need to mention CLI and SNMP




> This question also applied to the Entity Tag in the next subsection.
>
>
>
> Another question is since restconf is supposed to be a (simplified)
> version of netconf (providing =E2=80=9Ca subset of Netconf functionality=
=E2=80=9D) how
> would netconf provide the equivalent capability to its clients?
>
>
>


That is out of scope for this document



> Thanks,
>
> steve
>
>

Andy


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

--94eb2c125e189154e80538aa0482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I am working on edits, but I don=
9;t see any changes here...


On Mon, Jul 11, 2016 at 10:06 AM, Steve Truong (st=
ruong) <struong@cisco.com> wrote:











=C2=A0=C2=A0 If the RESTCONF=
 server is colocated with a NETCONF server, then the

=C2=A0=C2=A0 last-modified t=
imestamp MUST represent the "running" datastore.


=C2=A0


If the =E2=80=9Crunning=E2=80=9D datastore can also =
be accessed and changed by other servers such as CLI, SNMP, =E2=80=A6 how w=
ould the timestamp be reported?


=C2=A0

<=
/div>

The timestamp is reported the same way no matter w=
hy the datastore changed.
The sentence does not need to mention C=
LI and SNMP


=C2=A0


This question also applied to the Entity Tag in the =
next subsection.


=C2=A0


Another question is since restconf is supposed to be=
 a (simplified) version of netconf (providing =E2=80=9Ca subset of Netconf =
functionality=E2=80=9D) how would netconf provide the equivalent capability=
 to its clients?


=C2=A0

<=
/div>

That is out of scope for this document
<=
br>
=C2=A0


Thanks,


steve









Andy
=C2=A0
________________________________________=
_______

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c125e189154e80538aa0482--


From nobody Thu Jul 28 03:53:51 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCDC12DE69 for ; Thu, 28 Jul 2016 03:53:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7WobST-ipJO for ; Thu, 28 Jul 2016 03:53:47 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0137.outbound.protection.outlook.com [104.47.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD8B12DC87 for ; Thu, 28 Jul 2016 03:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HK3daN15RZeyUgCY8/rtsMspttrdAlnDXBq5yUfV0II=; b=KBapIYLKcBhXZrYLXMUNCF/GYypFq1l04KGeAPNObwSGmisKMuliRQTbM5qNyuIR3NhymJeJpCa/lFSFk9XJKH1madrThx42ufaHugiO8aGXI7DMrYAixDgdCw5FAVRMj23sdPFzJ4whCXsYMSvv9xAbqyewuCui8K1BPsdBvJE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (31.50.86.164) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Thu, 28 Jul 2016 10:53:40 +0000
Message-ID: <016c01d1e8bd$f3c6a580$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Ersue, Mehmet (Nokia - DE/Munich)" , Netconf 
References: 
Date: Thu, 28 Jul 2016 11:49:57 +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: [31.50.86.164]
X-ClientProxiedBy: DB3PR05CA0036.eurprd05.prod.outlook.com (10.160.41.164) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149)
X-MS-Office365-Filtering-Correlation-Id: a9ceb90a-bc8a-4ad5-bd45-08d3b6d56f5f
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:qnj2Xe20Y3gjBoFA6FjQyewv57wT8cWcqf4k7e6TQbajNBV0ydbo4qV9fFhj7CLOQPOzUxC3/TeRkoB6DHHEuzRuXJUxQAFnkFcfJqk1VO790oGzveWwjth9AX8Ra+tqTn2VKaoGR4pUhOKaZMKYqmXnveYOIyStLDVZsE8M/jZ6+WL35UQm9O0R/655FYlQ; 3:UnK6uZLJaTXsoSJ242jaIAoGK2y/4TWb6jm7TRwV5T1ULHp2bBMBT/TY5HIqKefzRtbKWDTSKyUstlCSk/5ogZAmlq9J95x5vtcxAgAZ6LA6VlgIIQCfdgYf+1yXflj3; 25:7DT9r5L4jL2pSBHOaYhejbCugkT/Ix+nr5rnKcIIXjYMIYDce2TVt49jwJzmsQZUY0w9NBtTTlGqK+lRds5WaiuAJOJzJGa+bLcmBfSrUZ2pdFbliHVMtT3iT6hr59qvF8/sGFo3iSFgNd/NUDMLoZOkWtR59y491RodenNYewn4lBPAxxEvQESHlCLws2KwzJc7CX5QeNNeoxfwfekCPMtD/khODrd3YnDrG5dSMQfSyO3os0EaVZGdeb6EppPvxNiXFBkmRDKyWyNSy3HVNz7fvS1zqgiCjraD/pLxkYnFqPafYtIpGo2p1SSYcdZ2lAAY+dwuDKi7BC93ILiegOrQzdldPx4fMLAFUBVu5RXoKKo82HBeniEAHnp5cj3gqqlRzN4fh0tCXd3kacDoclEUHrDZYfSdVkOx105Ie+8=; 31:rf59CmN7Xmqi2Zpk51ODbCR2GISwlICR/T4g2bGUybdhJs8ipNIqQTkoSVwkla4gefoWolTCMT0qoz39SjxUL5zyMDSDHJzZG0gi92HnxeWudu9+r7ko4SR+uUx3KxUHdufv32xGnaBJaEshfz9t8K39bk3EQ16qjdwxsHt3kVHGotM4wmJk+W3TZZYlTIGTvJix2Evc71oTMT4f2rUdTg==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(82608151540597);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; 
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:6I5hQm/Do0Ok35CliHGHDRl2XqI+uAc9nB/XCDs66r4nlkfTLu27ypmxdgdFFYdQXjP5mbmrD0pWsfGSY0+T4M7i8ncUQoPjFzb9X5sOXRPFBEoYW/onynknl7hMALdjwIS8luVwrgt1wsdHScOVsgllAluujAPFQ2Dgo8UjJgYcyITbKb+2Kwy4rD5qieGEDi4sGLhYbw9QD8sxeWDvmOr/43zcagt4uqLOPKrc5ElhE4nJ2h5iqaEUQzoAct1M/61Q49/D0BuvEKFbuQq0AYhkEY0D+RMKC/D+GOO0h+ZQojWGlXd/Kpi+9FPyyiN+PF9nTrzEaV5I2xKAHM+D1M9ODoEVdj+fSImrl/czeX7e4I1QWK0Ij/NTO4AmHivkbtCi+e1Ig1mjCsdYLrU4M1ovw7hZA5T01mk1SXq4gkw=
X-Forefront-PRVS: 00179089FD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(377454003)(51444003)(13464003)(189002)(81686999)(92566002)(50986999)(76176999)(14496001)(50226002)(81816999)(116806002)(33646002)(61296003)(97736004)(7846002)(86362001)(47776003)(9686002)(23756003)(7736002)(19580405001)(5001770100001)(44716002)(62236002)(66066001)(305945005)(189998001)(101416001)(107886002)(106356001)(1556002)(105586002)(19580395003)(8676002)(6116002)(586003)(44736004)(84392002)(2906002)(15975445007)(1456003)(3846002)(77096005)(230700001)(42186005)(50466002)(81166006)(68736007)(81156014)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1622; 23:Z2w+mWA+KIxBVHsCvjnEWv1h9N4I/tW6c609+/P?= =?iso-8859-1?Q?VCvSvwIrWZC8dLJhJWsWxklU4RoKEpo/y1p1dqgHsC42r7A8ge9Qx6PWpj?= =?iso-8859-1?Q?11KZ9TU/kS9ybJLQrddcY8vDfGElI8A+VD6mNMGQ0Xin/qm621QfQJCXTD?= =?iso-8859-1?Q?LE9OcVIbXS30B2IkGh68N2vU/4wXeIgCINLonvSasTFBODYrNTm611wC78?= =?iso-8859-1?Q?9nJ0eY5z2uM0Ss19eYoieHKXMR01OW0zlr6c9jpUL7AybmtdKH4HwAg0+Q?= =?iso-8859-1?Q?DLnZRd3OaCsl1HOxurL+tOGh1FwJLV6eh+h89mb2ae3B2/FiDB7Cihzwb+?= =?iso-8859-1?Q?yMlD4SHuYe0WzWVy8lkZcxjsoIDd+h9vu1MydCXfGvTr/jk6hejwMc1BXz?= =?iso-8859-1?Q?XlGASyW2cTCPiaK1Lv/G3CG/keLinYQTL4pTNQoW4r20XsLIVocPU6Kd9N?= =?iso-8859-1?Q?SJqfK9HRsBs9XFqSDyBnLMQVwO006XZVjBFEQYI2KwXo7mKBuJSdEftQv+?= =?iso-8859-1?Q?vmc/uqirnPIocToD7r5ijH04ptPlEv6MYR6xkSacczyd9N0HLygC8Zi38v?= =?iso-8859-1?Q?SxmbGBsDfEsBBPEB1damY8ItaTTpV3PVw8Xa30S7pLus+7GM7liBIy+tAq?= =?iso-8859-1?Q?s4iLck/sg6tYvt8PhcNDbVdjOPGjVc5LCRRG/WinPuB4SYo2dp43Mqa0UM?= =?iso-8859-1?Q?xxlGwqJdAqL6Wvf43U1LpbjmUbbKZGN1TwiFntfT8LQFD9YWpbgd5OBa1k?= =?iso-8859-1?Q?TsQlsYN5fqw+qlZKa2o1qxNGPfx6K9Rrr66j6H+/38q41gIb8/uHPZKjqQ?= =?iso-8859-1?Q?5aScq74ONin5sIKmC6RHjwnwHZYCIS/PwDLmc5FRqdZfOyN0QAStIAcV3W?= =?iso-8859-1?Q?n/tvEM8qHdtKo5BJBZuh820E5ZCmB55p3fRslMX+bDM2lQg9IH6RFiLktf?= =?iso-8859-1?Q?aL0SkLkht20Ds0A0VBRvJYdzJzx7mZXKvL9FWLf12Rjie9x9ZRSNdkB7rL?= =?iso-8859-1?Q?ZnzVES8XeF9neIb9je+EquEF+QMQqLQ7qfELV6FwPY7sU7Ytj/UBWYta6R?= =?iso-8859-1?Q?UxwhiTTm664BgHg6GcMJLdfLJmAS9qUwVJVFb9RQoYzL4KsErGJTSBazz+?= =?iso-8859-1?Q?zFs0MuYdEqRUpJsErSgxLNMx0RlRYzR9FDyYy46BwQokkwgVtliWp8ULA9?= =?iso-8859-1?Q?yn2TBew2cNmTQyrFLY/mnWy0GJ/uoUMKFE2oAk6E01DWMRYIWcoAnWiwj0?= =?iso-8859-1?Q?lsoZAdnuvRxX+Ug5NdXlAv6swM8fia0QWVuCItwZkFzCRi3U2q08/mV0N+?= =?iso-8859-1?Q?phBUCpK7Gd1P8QeHNd2ka7L5CpYlQR0XtxRtXQVfYcsCcq89ORGyWIQB+C?= =?iso-8859-1?Q?/6Eis5J4+wjhAPWc5RSvwvmYz0YCrJoGho6JGwfT3z0fqbeofRChPNdPzX?= =?iso-8859-1?Q?4R5HrOpDVdKjdgNn4dDrzrvx0Y30YMnLS/r?=
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:cPWp1sQZA+kIyZ7o0R7BftB9JVKpv/YBEop9TihdD0JeJo0WX5ygMAXNbzVbkcNsJF/xHtOq53eWDS2eIqdrXFuRdh21e6XnevoP6j3EMdEbEaEk2xvQTplhwP9/WsXadcQhq8FVN/9RDUqLHziTg68Iw4OKYt0/AsNZLMtEZTViTg3lp30LbOtjgLrUh75t3tJG/n4nAbeYbx2LyUYzdZXMbbhUDIi7ebFih9i5PFt4gxodA6tycStYIEU+8P2IUpdixgl4utD0frZj58eSPfJwcIo8IbXCb6WjwgBXSTw=; 5:yTuACPKo9CGJvqnBZ+BE4ozHfyqA1f1fmWydtVzlhEDFg8DuFw9Vgw2XHENz5U+9fFTUkWQwT+BXS9Y1mD/qmb2aZLL7lp0FlIwqH0yQHVqZLf9qxL/lLParRzj9GZr0tI2y8ieH7ZqdSKbxL6dCtw==; 24:U1FJPHiowjtH6AMp4S2lelDtK/083csxwG/1jQDlbZtvfBX5pyXzBN6m0MrnwYNwlOg6c5JpHrzMWY0dN/u+O+ccdnv6IdtWkT0tDI7SnEQ=; 7:t/Yo0fB7eD2Vk1mD6rAzZbXHtG7zmiSDLPAp/kFdO1nsyxhMuKUbTKBMH3QeXvzWl4+MNVBW5VmWBHQ/waZhXe9A79I7FT4hQwFzcEdqUZJ7+3yk9ldeZLP9eI4IAv0ytZYvFlM2F4b9f8sUTQnXeAZZhchG/qUApYvhl1fxskr9iSrTwK3GfEPPbjiXwaxA5c4fMye2sLOB/fJ27YZ4cI2KWhfZ5FVhsRcQgFW66/iFwyovph1HXfeZYRw4e7ig
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2016 10:53:40.0018 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622
Archived-At: 
Subject: Re: [Netconf] Draft Minutes of IETF 96 NETCONF Session
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 10:53:50 -0000

I notice that Benoit floats the idea of changing the name of the group.

I think that this is a bad idea.  I always think it a bad idea to
overload a short, simple, easy-to-use identifier with specific,
time-limited semantics which try to pin down the object identified.

The IETF is littered with examples of  this approach.  Consider, in this
case, what would we do with the names of I-Ds, how would we ever link
future incarnations with previous ones, not just of I-Ds but of minutes,
wikis, and all the other computer systems where NETCONF currently is
used as an identifier?

Tom Petch


----- Original Message -----
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: "Netconf" 
Sent: Tuesday, July 26, 2016 9:38 PM

Dear NETCONF WG,

below are the draft minutes of the NETCONF session in IETF 96 meeting.

https://www.ietf.org/proceedings/96/minutes/minutes-96-netconf

Please send a note to the co-chairs by August 2nd EOB, if you have
request any changes.

Mehmet & Mahesh





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


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


From nobody Thu Jul 28 04:07:00 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28E612DED9 for ; Thu, 28 Jul 2016 04:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.207
X-Spam-Level: 
X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 4VDGdIreEukf for ; Thu, 28 Jul 2016 04:06:58 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C8212DEE2 for ; Thu, 28 Jul 2016 04:06:58 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EQAgDT5plX/yYyC4ddGwEBAYJ6LYFSB?= =?us-ascii?q?o0lqTiCD4F9hh0CgTk4FAEBAQEBAQEDWieEXAEBAQEDEihLBAIBCA0EBAEBCxQ?= =?us-ascii?q?JBzIUCQgCBAESCBqIDwGjPpgeAQEBAQEFAQEBAQEBASCGK4RMhBwmgyqCLwWOF?= =?us-ascii?q?oscAYwGhHiHaIVVjC6DeB42g3puhzNFAX4BAQE?=
X-IPAS-Result: =?us-ascii?q?A2EQAgDT5plX/yYyC4ddGwEBAYJ6LYFSBo0lqTiCD4F9hh0?= =?us-ascii?q?CgTk4FAEBAQEBAQEDWieEXAEBAQEDEihLBAIBCA0EBAEBCxQJBzIUCQgCBAESC?= =?us-ascii?q?BqIDwGjPpgeAQEBAQEFAQEBAQEBASCGK4RMhBwmgyqCLwWOFoscAYwGhHiHaIV?= =?us-ascii?q?VjC6DeB42g3puhzNFAX4BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,433,1464667200"; d="scan'208";a="185471950"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Jul 2016 07:06:57 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 28 Jul 2016 07:06:56 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0294.000; Thu, 28 Jul 2016 13:06:55 +0200
From: "Romascanu, Dan (Dan)" 
To: t.petch , "Ersue, Mehmet (Nokia - DE/Munich)" , Netconf 
Thread-Topic: [Netconf] Draft Minutes of IETF 96 NETCONF Session
Thread-Index: AQHR6L5XmZVR137mnkmOVjR7xJtKk6AtrrQA
Date: Thu, 28 Jul 2016 11:06:54 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752544B5@AZ-FFEXMB04.global.avaya.com>
References:  <016c01d1e8bd$f3c6a580$4001a8c0@gateway.2wire.net>
In-Reply-To: <016c01d1e8bd$f3c6a580$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Draft Minutes of IETF 96 NETCONF Session
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 11:06:59 -0000

I agree with Tom here.=20

Regards,

Dan


> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of t.petch
> Sent: Thursday, July 28, 2016 1:50 PM
> To: Ersue, Mehmet (Nokia - DE/Munich); Netconf
> Subject: Re: [Netconf] Draft Minutes of IETF 96 NETCONF Session
>=20
> I notice that Benoit floats the idea of changing the name of the group.
>=20
> I think that this is a bad idea.  I always think it a bad idea to overloa=
d a short,
> simple, easy-to-use identifier with specific, time-limited semantics whic=
h try
> to pin down the object identified.
>=20
> The IETF is littered with examples of  this approach.  Consider, in this =
case,
> what would we do with the names of I-Ds, how would we ever link future
> incarnations with previous ones, not just of I-Ds but of minutes, wikis, =
and all
> the other computer systems where NETCONF currently is used as an
> identifier?
>=20
> Tom Petch
>=20
>=20
> ----- Original Message -----
> From: "Ersue, Mehmet (Nokia - DE/Munich)" 
> To: "Netconf" 
> Sent: Tuesday, July 26, 2016 9:38 PM
>=20
> Dear NETCONF WG,
>=20
> below are the draft minutes of the NETCONF session in IETF 96 meeting.
>=20


From nobody Thu Jul 28 06:18:21 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6385812D6B5 for ; Thu, 28 Jul 2016 06:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=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 H4GVnRxYjeDw for ; Thu, 28 Jul 2016 06:18:18 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EF54B12DA7B for ; Thu, 28 Jul 2016 06:11:41 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 122121CC021B; Thu, 28 Jul 2016 15:11:47 +0200 (CEST)
From: Ladislav Lhotka 
To: "Romascanu\, Dan \(Dan\)" , "t.petch" , "Ersue\, Mehmet \(Nokia - DE\/Munich\)" , Netconf 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA752544B5@AZ-FFEXMB04.global.avaya.com>
References:  <016c01d1e8bd$f3c6a580$4001a8c0@gateway.2wire.net> <9904FB1B0159DA42B0B887B7FA8119CA752544B5@AZ-FFEXMB04.global.avaya.com>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 28 Jul 2016 15:11:48 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [Netconf] Draft Minutes of IETF 96 NETCONF Session
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jul 2016 13:18:19 -0000

"Romascanu, Dan (Dan)"  writes:

> I agree with Tom here.

+1

Lada

>
> Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of t.petch
>> Sent: Thursday, July 28, 2016 1:50 PM
>> To: Ersue, Mehmet (Nokia - DE/Munich); Netconf
>> Subject: Re: [Netconf] Draft Minutes of IETF 96 NETCONF Session
>> 
>> I notice that Benoit floats the idea of changing the name of the group.
>> 
>> I think that this is a bad idea.  I always think it a bad idea to overload a short,
>> simple, easy-to-use identifier with specific, time-limited semantics which try
>> to pin down the object identified.
>> 
>> The IETF is littered with examples of  this approach.  Consider, in this case,
>> what would we do with the names of I-Ds, how would we ever link future
>> incarnations with previous ones, not just of I-Ds but of minutes, wikis, and all
>> the other computer systems where NETCONF currently is used as an
>> identifier?
>> 
>> Tom Petch
>> 
>> 
>> ----- Original Message -----
>> From: "Ersue, Mehmet (Nokia - DE/Munich)" 
>> To: "Netconf" 
>> Sent: Tuesday, July 26, 2016 9:38 PM
>> 
>> Dear NETCONF WG,
>> 
>> below are the draft minutes of the NETCONF session in IETF 96 meeting.
>> 
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Jul 29 13:11:50 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2E912D86C; Fri, 29 Jul 2016 13:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 hEN7jPme0mH4; Fri, 29 Jul 2016 13:11:46 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65512D86A; Fri, 29 Jul 2016 13:11:46 -0700 (PDT)
Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6TKBjTx082092 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 29 Jul 2016 15:11:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local
To: General Area Review Team , "ietf@ietf.org" , netconf@ietf.org, draft-ietf-netconf-restconf.all@ietf.org
From: Robert Sparks 
Message-ID: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>
Date: Fri, 29 Jul 2016 15:11:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 20:11:48 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-netconf-restconf-15
Reviewer: Robert Sparks
Review Date: 28Jul2016
IETF LC End Date: 3Aug2016
IESG Telechat date: not yet scheduled

Summary:

Major issues:

* I am not finding any discussion in the Security Considerations or in 
the text around what a server's options are if a client is asking it to 
keep more state than it is willing or capable of holding. The possible 
values of the "depth" query parameter (particularly "unbounded") points 
out that a misconfigured or compromised client might start creating 
arbitrarily deep trees. Should a server have the ability to say no?

* The third paragraph of 3.7 paraphrases to "SHOULD NOT delete more than 
one instance unless a proprietary query parameter says it's ok". This 
isn't really helpful in a specification. Proprietary things are 
proprietary. The SHOULD NOT already allows proprietary things to do 
something different without trainwrecking the protocol. Please just 
delete the 2nd and 3rd sentence from the paragraph.

* Section 2.3 says "If X.509 certificate path validation fails and the 
presented X.509 certificate does not match a locally configured 
certificate fingerprint, the connection MUST be terminated as defined in 
[RFC5246]." RFC5246 doesn't really talk about certificate validation, 
and it certainly doesn't say "the connection MUST be terminated" when 
certificates fail to validate. What are you trying to point to in 
RFC5246 here? Should you be pointing somewhere else? (It's perfectly 
reasonable for the document to reference RFC5246, and it does so 
elsewhere without problem).

Minor issues:

* "A server MUST support XML or JSON encoding." is ambiguous. (2nd 
paragraph of 5.2). Did you mean the server MUST support at least one of 
XML or JSON but not necessarily both? I think you really intended that 
the server support BOTH types of encoding.

* I _think_ I can infer that PUT can't be used with datastore resources. 
Section 3.4 only speaks of POST and PATCH. Section 4.5 speaks about 
"target data resource" and is silent about datastore resources. If I've 
understood the intent, please be explicit about datastore resources in 
4.5. If I've misunderstood then more clarity is needed in both 3.4 and 4.5.

* In 3.5.3.1 you restrict identifiers with "MUST NOT start with 'xml' 
(or any case variant of that string). Please call out why (or point to 
an existing document that explains why).

* The text in 5.3 about access control interacting with caching (added 
based on my early review I think) doesn't mesh well with paragraph 3 of 
section 5.5. There you tell the client to use Etag and Last-Modified, 
but in 5.3 you say it won't work reliably when access permissions 
change. At the very least 5.5 should point back into the paragraph in 5.3.

Nits/editorial comments:

* Introduction, 4th paragraph - please change "MAY provide" to 
"provides". Section 3.6 explains the cases where there is choice in what 
to provide.


* Section 2.3 paragraphs 1 and 2. There is edit-itis here left (I 
suspect) from working in matching fingerprints. Consider combining and 
simplifying these two paragraphs after improving the reference issue 
called out above.

* Section 4 says "Access control mechanisms MUST be used to limit..." 
This is not a good use of a 2119 MUST. I suggest replacing "MUST be" 
with "are". The subsequent text already captures the actual normative 
requirements on the server.

* Section 12 says "this protocol SHOULD be implemented carefully". That 
is not a good use of a 2119 SHOULD. It is not a protocol requirement. I 
suggest reformulating this into something like "There are many patterns 
of attack that have been observed through operational practice with 
existing management interfaces. It would be wise for implementers to 
research them, and take them into account when implementing this 
protocol." It would be far better to provide a pointer to where the 
implementer should start this research.

* (micronit) Lots of examples are internally inconsistent wrt dates. For 
instance, look at the 200 OK in section 3.3.3 - it says that back in 
2012, a server returned something talking about a library versioned in 2016.


From nobody Fri Jul 29 13:37:02 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0D812D87E for ; Fri, 29 Jul 2016 13:36:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhfXScE655Hb for ; Fri, 29 Jul 2016 13:36:56 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECE612D871 for ; Fri, 29 Jul 2016 13:36:55 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id l32so69787746ual.2 for ; Fri, 29 Jul 2016 13:36:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y2E/7l4KhSVXrx4majPbGM/Rq+bq866fk/6YHW4tR1A=; b=W6A/xIdMxoUI5jAz9Z/iK1P+yftHIcrUKQyEyRT+F6mpPF8HoFiIku7bcVugEI6S50 yGkjG7iMLORCJp5PdSYlCjUvmunn1rvAcSHr8n6wMpKkrLBCgWBampPN4jfthyA9duAq bDCVOYKOwVCJf+cmc+0OhGHRY7ygRoMbnCvktYBF3XqGs1MKJbORhguq+6mr+th3he4u KqBP3MerbmdMqvUbRNy71NKnuCJ7fi79hsQ8sPZsHakZI9rbCoMYvLKA142OqLcsiqLW AFWNn/m5k1cLD0Hj9ERkaUz+IW1Ixa0gZLH4XEEkTWBYkRow+f5H6BOwlmqSuUv4tm0v y/Zg==
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; bh=Y2E/7l4KhSVXrx4majPbGM/Rq+bq866fk/6YHW4tR1A=; b=HWdLIvuF35N+rbQZt+NsZneULjhKrXk8HivK2LuaTxWZdlopQuUNBorlhnnHUFSA35 oFOo3npvYpHMGgzhmnVPwDnzTF8/nzaFaxSjHVntAs6/3asp+BurUWUYf/SFCztn4oNz WMcxYYXPlQ6OYX0NWN+xX7M3NQgcnDPrrZSNMaRvhB86MqxlCQ1I/Wd2MNzD9BEWKPlK gYgoyiAob6EVMGtUCxkvubVgw96LWGaOadhVYhv6f8db4neBOAarirax054aaqJzF905 j+Lshs5So8zG5lpNHy6SzcfsokDPoVZ3eIZaFoWLYBjD0UbffzdeLZbz6JZBJubfywjV 6r8g==
X-Gm-Message-State: AEkooutU3dlJqzw4LUAlsHS43cN+QgiZy/SZc7x7IEyeXOCWdkv+oNXpFnuvk3ZnX4ovS/zsm9yLozckV6tOcQ==
X-Received: by 10.176.67.4 with SMTP id k4mr19777127uak.47.1469824614969; Fri, 29 Jul 2016 13:36:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Fri, 29 Jul 2016 13:36:54 -0700 (PDT)
In-Reply-To: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>
From: Andy Bierman 
Date: Fri, 29 Jul 2016 13:36:54 -0700
Message-ID: 
To: Robert Sparks 
Content-Type: multipart/alternative; boundary=94eb2c09507a0ed21f0538cc363a
Archived-At: 
Cc: General Area Review Team , draft-ietf-netconf-restconf.all@ietf.org, "ietf@ietf.org" , Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 20:36:59 -0000

--94eb2c09507a0ed21f0538cc363a
Content-Type: text/plain; charset=UTF-8

Hi,

I will add this review to the list.
A new version in in progress.
Some comments inline


On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks  wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-netconf-restconf-15
> Reviewer: Robert Sparks
> Review Date: 28Jul2016
> IETF LC End Date: 3Aug2016
> IESG Telechat date: not yet scheduled
>
> Summary:
>
> Major issues:
>
> * I am not finding any discussion in the Security Considerations or in the
> text around what a server's options are if a client is asking it to keep
> more state than it is willing or capable of holding. The possible values of
> the "depth" query parameter (particularly "unbounded") points out that a
> misconfigured or compromised client might start creating arbitrarily deep
> trees. Should a server have the ability to say no?
>


I guess we need more text somewhere explaining the "depth" parameter is
a retrieval filter.  It is not used to create anything in the server.
The server does not maintain any state except during the processing of
the retrieval request



>
> * The third paragraph of 3.7 paraphrases to "SHOULD NOT delete more than
> one instance unless a proprietary query parameter says it's ok". This isn't
> really helpful in a specification. Proprietary things are proprietary. The
> SHOULD NOT already allows proprietary things to do something different
> without trainwrecking the protocol. Please just delete the 2nd and 3rd
> sentence from the paragraph.
>

OK


>
> * Section 2.3 says "If X.509 certificate path validation fails and the
> presented X.509 certificate does not match a locally configured certificate
> fingerprint, the connection MUST be terminated as defined in [RFC5246]."
> RFC5246 doesn't really talk about certificate validation, and it certainly
> doesn't say "the connection MUST be terminated" when certificates fail to
> validate. What are you trying to point to in RFC5246 here? Should you be
> pointing somewhere else? (It's perfectly reasonable for the document to
> reference RFC5246, and it does so elsewhere without problem).
>


Please suggest replacement text if we are citing the wrong RFC.
I will ask Kent to look into this issue



>
> Minor issues:
>
> * "A server MUST support XML or JSON encoding." is ambiguous. (2nd
> paragraph of 5.2). Did you mean the server MUST support at least one of XML
> or JSON but not necessarily both? I think you really intended that the
> server support BOTH types of encoding.
>

No -- it will be clarified that the server must support at least 1 of the 2



>
> * I _think_ I can infer that PUT can't be used with datastore resources.
> Section 3.4 only speaks of POST and PATCH. Section 4.5 speaks about "target
> data resource" and is silent about datastore resources. If I've understood
> the intent, please be explicit about datastore resources in 4.5. If I've
> misunderstood then more clarity is needed in both 3.4 and 4.5.
>
>
The  next draft will be clarified to allow PUT on a datastore resource


> * In 3.5.3.1 you restrict identifiers with "MUST NOT start with 'xml' (or
> any case variant of that string). Please call out why (or point to an
> existing document that explains why).
>

OK


>
> * The text in 5.3 about access control interacting with caching (added
> based on my early review I think) doesn't mesh well with paragraph 3 of
> section 5.5. There you tell the client to use Etag and Last-Modified, but
> in 5.3 you say it won't work reliably when access permissions change. At
> the very least 5.5 should point back into the paragraph in 5.3.
>
> Nits/editorial comments:
>
> * Introduction, 4th paragraph - please change "MAY provide" to "provides".
> Section 3.6 explains the cases where there is choice in what to provide.
>
>
> * Section 2.3 paragraphs 1 and 2. There is edit-itis here left (I suspect)
> from working in matching fingerprints. Consider combining and simplifying
> these two paragraphs after improving the reference issue called out above.
>
> * Section 4 says "Access control mechanisms MUST be used to limit..." This
> is not a good use of a 2119 MUST. I suggest replacing "MUST be" with "are".
> The subsequent text already captures the actual normative requirements on
> the server.
>
> * Section 12 says "this protocol SHOULD be implemented carefully". That is
> not a good use of a 2119 SHOULD. It is not a protocol requirement. I
> suggest reformulating this into something like "There are many patterns of
> attack that have been observed through operational practice with existing
> management interfaces. It would be wise for implementers to research them,
> and take them into account when implementing this protocol." It would be
> far better to provide a pointer to where the implementer should start this
> research.
>
> * (micronit) Lots of examples are internally inconsistent wrt dates. For
> instance, look at the 200 OK in section 3.3.3 - it says that back in 2012,
> a server returned something talking about a library versioned in 2016.
>
>

Andy

--94eb2c09507a0ed21f0538cc363a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I will add this review to the list.=

A new version in in progress.
Some comments inline


On Fri=
, Jul 29, 2016 at 1:11 PM, Robert Sparks <rjsparks@nostrum.com><=
/span> wrote:
I am the assigned Gen-ART r=
eviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.=C2=A0 Please treat these comments just

like any other last call comments.



For more information, please see the FAQ at



<http://wiki.tools.ietf.org/area/gen/trac/=
wiki/GenArtfaq>.



Document: draft-ietf-netconf-restconf-15

Reviewer: Robert Sparks

Review Date: 28Jul2016

IETF LC End Date: 3Aug2016

IESG Telechat date: not yet scheduled



Summary:



Major issues:



* I am not finding any discussion in the Security Considerations or in the =
text around what a server's options are if a client is asking it to kee=
p more state than it is willing or capable of holding. The possible values =
of the "depth" query parameter (particularly "unbounded"=
;) points out that a misconfigured or compromised client might start creati=
ng arbitrarily deep trees. Should a server have the ability to say no?
<=
/blockquote>


I guess we need more text so=
mewhere explaining the "depth" parameter is
a retrieval=
 filter.=C2=A0 It is not used to create anything in the server.
T=
he server does not maintain any state except during the processing of
=

the retrieval request

=C2=A0



* The third paragraph of 3.7 paraphrases to "SHOULD NOT delete more th=
an one instance unless a proprietary query parameter says it's ok"=
. This isn't really helpful in a specification. Proprietary things are =
proprietary. The SHOULD NOT already allows proprietary things to do somethi=
ng different without trainwrecking the protocol. Please just delete the 2nd=
 and 3rd sentence from the paragraph.

O=
K
=C2=A0



* Section 2.3 says "If X.509 certificate path validation fails and the=
 presented X.509 certificate does not match a locally configured certificat=
e fingerprint, the connection MUST be terminated as defined in [RFC5246].&q=
uot; RFC5246 doesn't really talk about certificate validation, and it c=
ertainly doesn't say "the connection MUST be terminated" when=
 certificates fail to validate. What are you trying to point to in RFC5246 =
here? Should you be pointing somewhere else? (It's perfectly reasonable=
 for the document to reference RFC5246, and it does so elsewhere without pr=
oblem).


Please suggest r=
eplacement text if we are citing the wrong RFC.
I will ask Kent t=
o look into this issue

=C2=A0



Minor issues:



* "A server MUST support XML or JSON encoding." is ambiguous. (2n=
d paragraph of 5.2). Did you mean the server MUST support at least one of X=
ML or JSON but not necessarily both? I think you really intended that the s=
erver support BOTH types of encoding.

N=
o -- it will be clarified that the server must support at least 1 of the 2<=
/div>

=C2=A0



* I _think_ I can infer that PUT can't be used with datastore resources=
. Section 3.4 only speaks of POST and PATCH. Section 4.5 speaks about "=
;target data resource" and is silent about datastore resources. If I&#=
39;ve understood the intent, please be explicit about datastore resources i=
n 4.5. If I've misunderstood then more clarity is needed in both 3.4 an=
d 4.5.



The =C2=A0next draft will be clarified=
 to allow PUT on a datastore resource
=C2=A0

* In 3.5.3.1 you restrict identifiers with "MUST NOT start with 'x=
ml' (or any case variant of that string). Please call out why (or point=
 to an existing document that explains why).

OK
=C2=A0



* The text in 5.3 about access control interacting with caching (added base=
d on my early review I think) doesn't mesh well with paragraph 3 of sec=
tion 5.5. There you tell the client to use Etag and Last-Modified, but in 5=
.3 you say it won't work reliably when access permissions change. At th=
e very least 5.5 should point back into the paragraph in 5.3.



Nits/editorial comments:



* Introduction, 4th paragraph - please change "MAY provide" to &q=
uot;provides". Section 3.6 explains the cases where there is choice in=
 what to provide.





* Section 2.3 paragraphs 1 and 2. There is edit-itis here left (I suspect) =
from working in matching fingerprints. Consider combining and simplifying t=
hese two paragraphs after improving the reference issue called out above.


* Section 4 says "Access control mechanisms MUST be used to limit...&q=
uot; This is not a good use of a 2119 MUST. I suggest replacing "MUST =
be" with "are". The subsequent text already captures the act=
ual normative requirements on the server.



* Section 12 says "this protocol SHOULD be implemented carefully"=
. That is not a good use of a 2119 SHOULD. It is not a protocol requirement=
. I suggest reformulating this into something like "There are many pat=
terns of attack that have been observed through operational practice with e=
xisting management interfaces. It would be wise for implementers to researc=
h them, and take them into account when implementing this protocol." I=
t would be far better to provide a pointer to where the implementer should =
start this research.



* (micronit) Lots of examples are internally inconsistent wrt dates. For in=
stance, look at the 200 OK in section 3.3.3 - it says that back in 2012, a =
server returned something talking about a library versioned in 2016.






Andy



--94eb2c09507a0ed21f0538cc363a--


From nobody Fri Jul 29 13:47:41 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379A612D512; Fri, 29 Jul 2016 13:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level: 
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 ZPBlFGWP_nL9; Fri, 29 Jul 2016 13:47:30 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277DA12B058; Fri, 29 Jul 2016 13:47:29 -0700 (PDT)
Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6TKlSnr085950 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 29 Jul 2016 15:47:28 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local
To: Andy Bierman 
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com> 
From: Robert Sparks 
Message-ID: 
Date: Fri, 29 Jul 2016 15:47:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1CEF6111B3BDE17C1FE2457B"
Archived-At: 
Cc: General Area Review Team , draft-ietf-netconf-restconf.all@ietf.org, "ietf@ietf.org" , Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 20:47:32 -0000

This is a multi-part message in MIME format.
--------------1CEF6111B3BDE17C1FE2457B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 7/29/16 3:36 PM, Andy Bierman wrote:
> Hi,
>
> I will add this review to the list.
> A new version in in progress.
> Some comments inline
>
>
> On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks  > wrote:
>
>     I am the assigned Gen-ART reviewer for this draft. The General Area
>     Review Team (Gen-ART) reviews all IETF documents being processed
>     by the IESG for the IETF Chair.  Please treat these comments just
>     like any other last call comments.
>
>     For more information, please see the FAQ at
>
>     .
>
>     Document: draft-ietf-netconf-restconf-15
>     Reviewer: Robert Sparks
>     Review Date: 28Jul2016
>     IETF LC End Date: 3Aug2016
>     IESG Telechat date: not yet scheduled
>
>     Summary:
>
>     Major issues:
>
>     * I am not finding any discussion in the Security Considerations
>     or in the text around what a server's options are if a client is
>     asking it to keep more state than it is willing or capable of
>     holding. The possible values of the "depth" query parameter
>     (particularly "unbounded") points out that a misconfigured or
>     compromised client might start creating arbitrarily deep trees.
>     Should a server have the ability to say no?
>
>
>
> I guess we need more text somewhere explaining the "depth" parameter is
> a retrieval filter.
I got that. It's existence, however, caused me to think about the fact 
that what is stored at the server can be arbitrarily deep. Clients using 
POST can build trees that are arbitrarily deep, with bits at the node 
that are arbitrarily large (subject to the constraints the YANG models 
put on the node). There should be some discussion acknowledging that 
this can happen, and discussion of what the server can do if some client 
starts asking it to store more than it is willing to store.
> It is not used to create anything in the server.
> The server does not maintain any state except during the processing of
> the retrieval request
>
>
>     * The third paragraph of 3.7 paraphrases to "SHOULD NOT delete
>     more than one instance unless a proprietary query parameter says
>     it's ok". This isn't really helpful in a specification.
>     Proprietary things are proprietary. The SHOULD NOT already allows
>     proprietary things to do something different without trainwrecking
>     the protocol. Please just delete the 2nd and 3rd sentence from the
>     paragraph.
>
>
> OK
>
>
>     * Section 2.3 says "If X.509 certificate path validation fails and
>     the presented X.509 certificate does not match a locally
>     configured certificate fingerprint, the connection MUST be
>     terminated as defined in [RFC5246]." RFC5246 doesn't really talk
>     about certificate validation, and it certainly doesn't say "the
>     connection MUST be terminated" when certificates fail to validate.
>     What are you trying to point to in RFC5246 here? Should you be
>     pointing somewhere else? (It's perfectly reasonable for the
>     document to reference RFC5246, and it does so elsewhere without
>     problem).
>
>
>
> Please suggest replacement text if we are citing the wrong RFC.
> I will ask Kent to look into this issue
>
>
>     Minor issues:
>
>     * "A server MUST support XML or JSON encoding." is ambiguous. (2nd
>     paragraph of 5.2). Did you mean the server MUST support at least
>     one of XML or JSON but not necessarily both? I think you really
>     intended that the server support BOTH types of encoding.
>
>
> No -- it will be clarified that the server must support at least 1 of 
> the 2
>
>
>     * I _think_ I can infer that PUT can't be used with datastore
>     resources. Section 3.4 only speaks of POST and PATCH. Section 4.5
>     speaks about "target data resource" and is silent about datastore
>     resources. If I've understood the intent, please be explicit about
>     datastore resources in 4.5. If I've misunderstood then more
>     clarity is needed in both 3.4 and 4.5.
>
>
> The  next draft will be clarified to allow PUT on a datastore resource
Hrmm - that makes me less comfortable that you are actually aligned with 
7231. It may just be that you need to be more precise with your 
description, but per 7231, PUT never creates resources - it can create 
or replace the state of a resource.
>
>     * In 3.5.3.1 you restrict identifiers with "MUST NOT start with
>     'xml' (or any case variant of that string). Please call out why
>     (or point to an existing document that explains why).
>
>
> OK
>
>
>     * The text in 5.3 about access control interacting with caching
>     (added based on my early review I think) doesn't mesh well with
>     paragraph 3 of section 5.5. There you tell the client to use Etag
>     and Last-Modified, but in 5.3 you say it won't work reliably when
>     access permissions change. At the very least 5.5 should point back
>     into the paragraph in 5.3.
>
>     Nits/editorial comments:
>
>     * Introduction, 4th paragraph - please change "MAY provide" to
>     "provides". Section 3.6 explains the cases where there is choice
>     in what to provide.
>
>
>     * Section 2.3 paragraphs 1 and 2. There is edit-itis here left (I
>     suspect) from working in matching fingerprints. Consider combining
>     and simplifying these two paragraphs after improving the reference
>     issue called out above.
>
>     * Section 4 says "Access control mechanisms MUST be used to
>     limit..." This is not a good use of a 2119 MUST. I suggest
>     replacing "MUST be" with "are". The subsequent text already
>     captures the actual normative requirements on the server.
>
>     * Section 12 says "this protocol SHOULD be implemented carefully".
>     That is not a good use of a 2119 SHOULD. It is not a protocol
>     requirement. I suggest reformulating this into something like
>     "There are many patterns of attack that have been observed through
>     operational practice with existing management interfaces. It would
>     be wise for implementers to research them, and take them into
>     account when implementing this protocol." It would be far better
>     to provide a pointer to where the implementer should start this
>     research.
>
>     * (micronit) Lots of examples are internally inconsistent wrt
>     dates. For instance, look at the 200 OK in section 3.3.3 - it says
>     that back in 2012, a server returned something talking about a
>     library versioned in 2016.
>
>
>
> Andy
>


--------------1CEF6111B3BDE17C1FE2457B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 7/29/16 3:36 PM, Andy Bierman wrote:

    

    

      
Hi,
        


        

        
I will add this review to the list.

        
A new version in in progress.

        
Some comments inline

        


          


            
On Fri, Jul 29, 2016 at 1:11 PM,
              Robert Sparks <rjsparks@nostrum.com>
              wrote:

              
I am
                the assigned Gen-ART reviewer for this draft. The
                General Area

                Review Team (Gen-ART) reviews all IETF documents being
                processed

                by the IESG for the IETF Chair.  Please treat these
                comments just

                like any other last call comments.

                

                For more information, please see the FAQ at

                

                <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

                

                Document: draft-ietf-netconf-restconf-15

                Reviewer: Robert Sparks

                Review Date: 28Jul2016

                IETF LC End Date: 3Aug2016

                IESG Telechat date: not yet scheduled

                

                Summary:

                

                Major issues:

                

                * I am not finding any discussion in the Security
                Considerations or in the text around what a server's
                options are if a client is asking it to keep more state
                than it is willing or capable of holding. The possible
                values of the "depth" query parameter (particularly
                "unbounded") points out that a misconfigured or
                compromised client might start creating arbitrarily deep
                trees. Should a server have the ability to say no?

              

              


              

              


              

              
I guess we need more text somewhere explaining the
                "depth" parameter is

              
a retrieval filter.  

            

          

        

      

    

    I got that. It's existence, however, caused me to think about the
    fact that what is stored at the server can be arbitrarily deep.
    Clients using POST can build trees that are arbitrarily deep, with
    bits at the node that are arbitrarily large (subject to the
    constraints the YANG models put on the node). There should be some
    discussion acknowledging that this can happen, and discussion of
    what the server can do if some client starts asking it to store more
    than it is willing to store.

    

      

        

          

            

              
It is not used to create anything in the server.

              
The server does not maintain any state except during
                the processing of

              
the retrieval request

              


              

              
 

              

                

                * The third paragraph of 3.7 paraphrases to "SHOULD NOT
                delete more than one instance unless a proprietary query
                parameter says it's ok". This isn't really helpful in a
                specification. Proprietary things are proprietary. The
                SHOULD NOT already allows proprietary things to do
                something different without trainwrecking the protocol.
                Please just delete the 2nd and 3rd sentence from the
                paragraph.

              

              


              

              
OK

              
 

              

                

                * Section 2.3 says "If X.509 certificate path validation
                fails and the presented X.509 certificate does not match
                a locally configured certificate fingerprint, the
                connection MUST be terminated as defined in [RFC5246]."
                RFC5246 doesn't really talk about certificate
                validation, and it certainly doesn't say "the connection
                MUST be terminated" when certificates fail to validate.
                What are you trying to point to in RFC5246 here? Should
                you be pointing somewhere else? (It's perfectly
                reasonable for the document to reference RFC5246, and it
                does so elsewhere without problem).

              

              


              

              


              

              
Please suggest replacement text if we are citing the
                wrong RFC.

              
I will ask Kent to look into this issue

              


              

              
 

              

                

                Minor issues:

                

                * "A server MUST support XML or JSON encoding." is
                ambiguous. (2nd paragraph of 5.2). Did you mean the
                server MUST support at least one of XML or JSON but not
                necessarily both? I think you really intended that the
                server support BOTH types of encoding.

              

              


              

              
No -- it will be clarified that the server must
                support at least 1 of the 2

              


              

              
 

              

                

                * I _think_ I can infer that PUT can't be used with
                datastore resources. Section 3.4 only speaks of POST and
                PATCH. Section 4.5 speaks about "target data resource"
                and is silent about datastore resources. If I've
                understood the intent, please be explicit about
                datastore resources in 4.5. If I've misunderstood then
                more clarity is needed in both 3.4 and 4.5.

                

              

              


              

              
The  next draft will be clarified to allow PUT on a
                datastore resource

            

          

        

      

    

    Hrmm - that makes me less comfortable that you are actually aligned
    with 7231. It may just be that you need to be more precise with your
    description, but per 7231, PUT never creates resources - it can
    create or replace the state of a resource.

    

      

        

          

            

              
 

              

                * In 3.5.3.1 you restrict identifiers with "MUST NOT
                start with 'xml' (or any case variant of that string).
                Please call out why (or point to an existing document
                that explains why).

              

              


              

              
OK

              
 

              

                

                * The text in 5.3 about access control interacting with
                caching (added based on my early review I think) doesn't
                mesh well with paragraph 3 of section 5.5. There you
                tell the client to use Etag and Last-Modified, but in
                5.3 you say it won't work reliably when access
                permissions change. At the very least 5.5 should point
                back into the paragraph in 5.3.

                

                Nits/editorial comments:

                

                * Introduction, 4th paragraph - please change "MAY
                provide" to "provides". Section 3.6 explains the cases
                where there is choice in what to provide.

                

                

                * Section 2.3 paragraphs 1 and 2. There is edit-itis
                here left (I suspect) from working in matching
                fingerprints. Consider combining and simplifying these
                two paragraphs after improving the reference issue
                called out above.

                

                * Section 4 says "Access control mechanisms MUST be used
                to limit..." This is not a good use of a 2119 MUST. I
                suggest replacing "MUST be" with "are". The subsequent
                text already captures the actual normative requirements
                on the server.

                

                * Section 12 says "this protocol SHOULD be implemented
                carefully". That is not a good use of a 2119 SHOULD. It
                is not a protocol requirement. I suggest reformulating
                this into something like "There are many patterns of
                attack that have been observed through operational
                practice with existing management interfaces. It would
                be wise for implementers to research them, and take them
                into account when implementing this protocol." It would
                be far better to provide a pointer to where the
                implementer should start this research.

                

                * (micronit) Lots of examples are internally
                inconsistent wrt dates. For instance, look at the 200 OK
                in section 3.3.3 - it says that back in 2012, a server
                returned something talking about a library versioned in
                2016.

                

              

            

            

          

        

        


        

        
Andy

        


        

      

    

    

  


--------------1CEF6111B3BDE17C1FE2457B--


From nobody Fri Jul 29 14:11:30 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46912D824 for ; Fri, 29 Jul 2016 14:11:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn-5FnOg_1WN for ; Fri, 29 Jul 2016 14:11:12 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C652312D88A for ; Fri, 29 Jul 2016 14:11:09 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id k90so70309876uak.0 for ; Fri, 29 Jul 2016 14:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n0/bTlsr03KyDVVLAevJERLYmhmdgF6s9Kcz5spDeEI=; b=VnhaEM/wCW8btWomirvhEt/9nguqhRPuqphwCeHDggXjGXA6j73Ro9wruuU8GckJkK LdQtouyEKlPO5Lz43wcLgXmoojLSEHEtriwKLYF7qDJJEoyv+FFrHmCm64hF7nrxriBk kvDwFBHfHIprTzq4rCXgBF1co8+m2UQgEkgbh729GcJjpqkw+zPNLcVNNz1D2as7clxc C5qfPza++mnH3u5zLgpqryWZJmKXPvUj9zAfZLQ5DPVnFGH1LnOOV2AILJZK9P0DA995 5Lm+6S1RJAUv9SjwvB1pbHm+6X6ig/zF5VgLNbmzlW3rYk78wW/deW65WIzf/UhPNp1l gHFQ==
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; bh=n0/bTlsr03KyDVVLAevJERLYmhmdgF6s9Kcz5spDeEI=; b=CYLtyyGygYPgjgqKTu5DrJFgPPHuUYv4IFY7p8y5dfOQZrWN7DYyUcRZ+dvZ/tTYSO xpSamY1JkzDAJ3D3wBxELSE8zKfHtWn6cud+frKoSxo8ktLAD3RFpUDcZIJs3f9FVB4N oE0LrKxSg2SMb+w4pE5Vm/LYwiYrg0lB2Zyqu7FonRUAkLvEJzXT5PWlRumhg+UbkdUr RmudeceHLlkWONKycbBXqH3hiWsWDRasF4d0IWfYN4rpEyApDcYD9i1MQ6Exw9ad/RtR E96/kvW1Ee1BxX/hZqtL4iVzFvrzO9TPTqbl0F5RtMWlPiF6WnrDmNCoo1AUO9zdtW8g dkBw==
X-Gm-Message-State: AEkoousnUeHD8JH5xopGmCQ9OiL1Gpfb0dOUHFPKOie3la8jI8cbA7xqe5xvjX82GYrff2K6DIQrqzHRJaYfZw==
X-Received: by 10.159.36.22 with SMTP id 22mr19495739uaq.105.1469826668725; Fri, 29 Jul 2016 14:11:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Fri, 29 Jul 2016 14:11:08 -0700 (PDT)
In-Reply-To: 
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>  
From: Andy Bierman 
Date: Fri, 29 Jul 2016 14:11:08 -0700
Message-ID: 
To: Robert Sparks 
Content-Type: multipart/alternative; boundary=001a11352aaa78cf710538ccb02f
Archived-At: 
Cc: General Area Review Team , draft-ietf-netconf-restconf.all@ietf.org, "ietf@ietf.org" , Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jul 2016 21:11:14 -0000

--001a11352aaa78cf710538ccb02f
Content-Type: text/plain; charset=UTF-8

On Fri, Jul 29, 2016 at 1:47 PM, Robert Sparks  wrote:

>
>
> On 7/29/16 3:36 PM, Andy Bierman wrote:
>
> Hi,
>
> I will add this review to the list.
> A new version in in progress.
> Some comments inline
>
>
> On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks 
> wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> .
>>
>> Document: draft-ietf-netconf-restconf-15
>> Reviewer: Robert Sparks
>> Review Date: 28Jul2016
>> IETF LC End Date: 3Aug2016
>> IESG Telechat date: not yet scheduled
>>
>> Summary:
>>
>> Major issues:
>>
>> * I am not finding any discussion in the Security Considerations or in
>> the text around what a server's options are if a client is asking it to
>> keep more state than it is willing or capable of holding. The possible
>> values of the "depth" query parameter (particularly "unbounded") points out
>> that a misconfigured or compromised client might start creating arbitrarily
>> deep trees. Should a server have the ability to say no?
>>
>
>
> I guess we need more text somewhere explaining the "depth" parameter is
> a retrieval filter.
>
> I got that. It's existence, however, caused me to think about the fact
> that what is stored at the server can be arbitrarily deep. Clients using
> POST can build trees that are arbitrarily deep, with bits at the node that
> are arbitrarily large (subject to the constraints the YANG models put on
> the node). There should be some discussion acknowledging that this can
> happen, and discussion of what the server can do if some client starts
> asking it to store more than it is willing to store.
>


Clients can build trees according to the YANG modules supported by the
server.
The YANG module has conformance requirements.
The protocols have 'resource-denied' errors.
Not sure what kind of warning they need.
An implementation may have no problem with 4 deep table entries,
but cannot store 100,000 flat table entries.



Andy



> It is not used to create anything in the server.
> The server does not maintain any state except during the processing of
> the retrieval request
>
>
>
>>
>> * The third paragraph of 3.7 paraphrases to "SHOULD NOT delete more than
>> one instance unless a proprietary query parameter says it's ok". This isn't
>> really helpful in a specification. Proprietary things are proprietary. The
>> SHOULD NOT already allows proprietary things to do something different
>> without trainwrecking the protocol. Please just delete the 2nd and 3rd
>> sentence from the paragraph.
>>
>
> OK
>
>
>>
>> * Section 2.3 says "If X.509 certificate path validation fails and the
>> presented X.509 certificate does not match a locally configured certificate
>> fingerprint, the connection MUST be terminated as defined in [RFC5246]."
>> RFC5246 doesn't really talk about certificate validation, and it certainly
>> doesn't say "the connection MUST be terminated" when certificates fail to
>> validate. What are you trying to point to in RFC5246 here? Should you be
>> pointing somewhere else? (It's perfectly reasonable for the document to
>> reference RFC5246, and it does so elsewhere without problem).
>>
>
>
> Please suggest replacement text if we are citing the wrong RFC.
> I will ask Kent to look into this issue
>
>
>
>>
>> Minor issues:
>>
>> * "A server MUST support XML or JSON encoding." is ambiguous. (2nd
>> paragraph of 5.2). Did you mean the server MUST support at least one of XML
>> or JSON but not necessarily both? I think you really intended that the
>> server support BOTH types of encoding.
>>
>
> No -- it will be clarified that the server must support at least 1 of the 2
>
>
>
>>
>> * I _think_ I can infer that PUT can't be used with datastore resources.
>> Section 3.4 only speaks of POST and PATCH. Section 4.5 speaks about "target
>> data resource" and is silent about datastore resources. If I've understood
>> the intent, please be explicit about datastore resources in 4.5. If I've
>> misunderstood then more clarity is needed in both 3.4 and 4.5.
>>
>>
> The  next draft will be clarified to allow PUT on a datastore resource
>
> Hrmm - that makes me less comfortable that you are actually aligned with
> 7231. It may just be that you need to be more precise with your
> description, but per 7231, PUT never creates resources - it can create or
> replace the state of a resource.
>
>
>
>> * In 3.5.3.1 you restrict identifiers with "MUST NOT start with 'xml' (or
>> any case variant of that string). Please call out why (or point to an
>> existing document that explains why).
>>
>
> OK
>
>
>>
>> * The text in 5.3 about access control interacting with caching (added
>> based on my early review I think) doesn't mesh well with paragraph 3 of
>> section 5.5. There you tell the client to use Etag and Last-Modified, but
>> in 5.3 you say it won't work reliably when access permissions change. At
>> the very least 5.5 should point back into the paragraph in 5.3.
>>
>> Nits/editorial comments:
>>
>> * Introduction, 4th paragraph - please change "MAY provide" to
>> "provides". Section 3.6 explains the cases where there is choice in what to
>> provide.
>>
>>
>> * Section 2.3 paragraphs 1 and 2. There is edit-itis here left (I
>> suspect) from working in matching fingerprints. Consider combining and
>> simplifying these two paragraphs after improving the reference issue called
>> out above.
>>
>> * Section 4 says "Access control mechanisms MUST be used to limit..."
>> This is not a good use of a 2119 MUST. I suggest replacing "MUST be" with
>> "are". The subsequent text already captures the actual normative
>> requirements on the server.
>>
>> * Section 12 says "this protocol SHOULD be implemented carefully". That
>> is not a good use of a 2119 SHOULD. It is not a protocol requirement. I
>> suggest reformulating this into something like "There are many patterns of
>> attack that have been observed through operational practice with existing
>> management interfaces. It would be wise for implementers to research them,
>> and take them into account when implementing this protocol." It would be
>> far better to provide a pointer to where the implementer should start this
>> research.
>>
>> * (micronit) Lots of examples are internally inconsistent wrt dates. For
>> instance, look at the 200 OK in section 3.3.3 - it says that back in 2012,
>> a server returned something talking about a library versioned in 2016.
>>
>>
>
> Andy
>
>
>

--001a11352aaa78cf710538ccb02f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jul 29, 2016 at 1:47 PM, Robert Sparks <rjsparks@nostrum.co=
m> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 7/29/16 3:36 PM, Andy Bierman wrote:

    

    

      
Hi,
        


        

        
I will add this review to the list.

        
A new version in in progress.

        
Some comments inline

        


          


            
On Fri, Jul 29, 2016 at 1:11 PM,
              Robert Sparks <rjsparks@nostrum.com>
              wrote:

              
I am
                the assigned Gen-ART reviewer for this draft. The
                General Area

                Review Team (Gen-ART) reviews all IETF documents being
                processed

                by the IESG for the IETF Chair.=C2=A0 Please treat these
                comments just

                like any other last call comments.

                

                For more information, please see the FAQ at

                

                <http://wiki.tools.ietf.or=
g/area/gen/trac/wiki/GenArtfaq>.

                

                Document: draft-ietf-netconf-restconf-15

                Reviewer: Robert Sparks

                Review Date: 28Jul2016

                IETF LC End Date: 3Aug2016

                IESG Telechat date: not yet scheduled

                

                Summary:

                

                Major issues:

                

                * I am not finding any discussion in the Security
                Considerations or in the text around what a server's
                options are if a client is asking it to keep more state
                than it is willing or capable of holding. The possible
                values of the "depth" query parameter (particular=
ly
                "unbounded") points out that a misconfigured or
                compromised client might start creating arbitrarily deep
                trees. Should a server have the ability to say no?

              

              


              

              


              

              
I guess we need more text somewhere explaining the
                "depth" parameter is

              
a retrieval filter.=C2=A0 

            

          

        

      

    

    I got that. It's existence, however, caused me to think about the
    fact that what is stored at the server can be arbitrarily deep.
    Clients using POST can build trees that are arbitrarily deep, with
    bits at the node that are arbitrarily large (subject to the
    constraints the YANG models put on the node). There should be some
    discussion acknowledging that this can happen, and discussion of
    what the server can do if some client starts asking it to store more
    than it is willing to store.

=

Clients can build trees according to the YANG modules suppor=
ted by the server.
The YANG module has conformance requirements.<=
/div>
The protocols have 'resource-denied' errors.
No=
t sure what kind of warning they need.
An implementation may have=
 no problem with 4 deep table entries,
but cannot store 100,000 f=
lat table entries.



A=
ndy

=C2=A0

    

      

        

          

            

              
It is not used to create anything in the server.

              
The server does not maintain any state except during
                the processing of

              
the retrieval request

              


              

              
=C2=A0

              

                

                * The third paragraph of 3.7 paraphrases to "SHOULD NO=
T
                delete more than one instance unless a proprietary query
                parameter says it's ok". This isn't really hel=
pful in a
                specification. Proprietary things are proprietary. The
                SHOULD NOT already allows proprietary things to do
                something different without trainwrecking the protocol.
                Please just delete the 2nd and 3rd sentence from the
                paragraph.

              

              


              

              
OK

              
=C2=A0

              

                

                * Section 2.3 says "If X.509 certificate path validati=
on
                fails and the presented X.509 certificate does not match
                a locally configured certificate fingerprint, the
                connection MUST be terminated as defined in [RFC5246]."=
;
                RFC5246 doesn't really talk about certificate
                validation, and it certainly doesn't say "the conn=
ection
                MUST be terminated" when certificates fail to validate=
.
                What are you trying to point to in RFC5246 here? Should
                you be pointing somewhere else? (It's perfectly
                reasonable for the document to reference RFC5246, and it
                does so elsewhere without problem).

              

              


              

              


              

              
Please suggest replacement text if we are citing the
                wrong RFC.

              
I will ask Kent to look into this issue

              


              

              
=C2=A0

              

                

                Minor issues:

                

                * "A server MUST support XML or JSON encoding." i=
s
                ambiguous. (2nd paragraph of 5.2). Did you mean the
                server MUST support at least one of XML or JSON but not
                necessarily both? I think you really intended that the
                server support BOTH types of encoding.

              

              


              

              
No -- it will be clarified that the server must
                support at least 1 of the 2

              


              

              
=C2=A0

              

                

                * I _think_ I can infer that PUT can't be used with
                datastore resources. Section 3.4 only speaks of POST and
                PATCH. Section 4.5 speaks about "target data resource&=
quot;
                and is silent about datastore resources. If I've
                understood the intent, please be explicit about
                datastore resources in 4.5. If I've misunderstood then
                more clarity is needed in both 3.4 and 4.5.

                

              

              


              

              
The =C2=A0next draft will be clarified to allow PUT on a
                datastore resource

            

          

        

      

    

    Hrmm - that makes me less comfortable that you are actually aligned
    with 7231. It may just be that you need to be more precise with your
    description, but per 7231, PUT never creates resources - it can
    create or replace the state of a resource.

    

      

        

          

            

              
=C2=A0

              

                * In 3.5.3.1 you restrict identifiers with "MUST NOT
                start with 'xml' (or any case variant of that strin=
g).
                Please call out why (or point to an existing document
                that explains why).

              

              


              

              
OK

              
=C2=A0

              

                

                * The text in 5.3 about access control interacting with
                caching (added based on my early review I think) doesn'=
t
                mesh well with paragraph 3 of section 5.5. There you
                tell the client to use Etag and Last-Modified, but in
                5.3 you say it won't work reliably when access
                permissions change. At the very least 5.5 should point
                back into the paragraph in 5.3.

                

                Nits/editorial comments:

                

                * Introduction, 4th paragraph - please change "MAY
                provide" to "provides". Section 3.6 explains=
 the cases
                where there is choice in what to provide.

                

                

                * Section 2.3 paragraphs 1 and 2. There is edit-itis
                here left (I suspect) from working in matching
                fingerprints. Consider combining and simplifying these
                two paragraphs after improving the reference issue
                called out above.

                

                * Section 4 says "Access control mechanisms MUST be us=
ed
                to limit..." This is not a good use of a 2119 MUST. I
                suggest replacing "MUST be" with "are".=
 The subsequent
                text already captures the actual normative requirements
                on the server.

                

                * Section 12 says "this protocol SHOULD be implemented
                carefully". That is not a good use of a 2119 SHOULD. I=
t
                is not a protocol requirement. I suggest reformulating
                this into something like "There are many patterns of
                attack that have been observed through operational
                practice with existing management interfaces. It would
                be wise for implementers to research them, and take them
                into account when implementing this protocol." It woul=
d
                be far better to provide a pointer to where the
                implementer should start this research.

                

                * (micronit) Lots of examples are internally
                inconsistent wrt dates. For instance, look at the 200 OK
                in section 3.3.3 - it says that back in 2012, a server
                returned something talking about a library versioned in
                2016.

                

              

            

            

          

        

        


        

        
Andy

        


        

      

    

    

  






--001a11352aaa78cf710538ccb02f--


From nobody Sat Jul 30 04:48:29 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E2F12B04B; Sat, 30 Jul 2016 04:48:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vPuaKsC5tNZ; Sat, 30 Jul 2016 04:48:21 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0103.outbound.protection.outlook.com [104.47.0.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D0212D1E3; Sat, 30 Jul 2016 04:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KWBH8riUgbtvCntEY+Fo33Om/5/f03GSI5KkFEIcZN8=; b=QxmY0E/2Sr1jkjMxfyYONxm4Y/VkR84irl34rQE/+SMpSAh+lNqWBgYEFG6hxinUbKj5F+mqRzrK9rL9RTmFoP48csiV6n7BQJsjHA7MuVt5E3cFiu/hkXhRhHEo2dcq+amr+yvvOfCZI338Kp9s8FTS9oY8CZBTN1ErRdnKSZo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (31.50.86.164) by VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sat, 30 Jul 2016 11:48:15 +0000
Message-ID: <00bc01d1ea57$e7889f80$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Robert Sparks 
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>  
Date: Sat, 30 Jul 2016 12:45:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
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: [31.50.86.164]
X-ClientProxiedBy: HE1PR05CA0011.eurprd05.prod.outlook.com (10.162.181.21) To VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149)
X-MS-Office365-Filtering-Correlation-Id: 5d26ed63-9202-43df-aed7-08d3b86f64c9
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 2:wo8RA6BRcJrxZpsqoKq6vKhRPB0flOuQptH5NaoE8IfDFL/d7RQj68XrDPaCDNZodsenQBN8+E+sCN2kSrFAYAVLuM//q5n7p+4XWXInRIkS8f4+jTk5OnnDXNT6pq2tXEPHRRoM1L7S/3drf+L57ueAgiVHWaqbFIzB+sTlO0A1gHJ+CWfsjZih70oygubt; 3:YuOTkUjp4H16NKm5OHLNe2xXCWf9lWRQSEWOMB7Ruv3R+2va7ve8y9b+87XpIUF22faWTKMXvw5WGrILQYz6SE9SweftGzdbXjYqiJR5GC7kbDopsZ+Q5evSMTif6QvM
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1631;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 25:Tb5D9ydxuMX/HHF+2lPhKR1VRN0SY1Oc64hSxJlwc1HzOe0oCTJcU0dlLZ0bVyqhcJY57R2n5aXP813DsrXjwj+l1fbVx9pPSlmrNp/g1bU/jklH+xRpQa2/7JjIbqYVkaPIGi61pf59NejrJJTYcA+EYgMtpQlKPNTNcgJy9ZP/7i+7DdGeyWVBD2bp2mzYn2yNQr6H3haK2YSt0tbtnQ33uO1CLcVSZAVa05biutZuqK/3N31azZ5HynI8KjI9jXjEKNazoL3pen0OCr+f40JRp5Y/cnDUr8gZYRb0HBBQ1BrIHPVYJTKZOCkkz4vNcpF+uObTpEjKX9RKYFtm9qAAKXjzpt7FQKxM65rD9lSI/JwsNaoVsLuPrpIAr+WAceMBuUHNEgHnQLeTYP8eFzzTGHRdzcyY+coFaz7+lzJ4+tjNnTnh+QMyLEtC53zCl5IttfT/+1xuB2aveYorPCN+9WIpqwoqgykZEzKjdCs/lHrk4ULNUt2vUZKbvro6uZDZV3Y5UslZvlwuTjqVGi2Y0wYcz6CyeL4M1g5s3r203B/4WYonE0HQgQoKrdp9Shhb34Z2XUmPrLir9hzDjOpG0L/WiwBEx4g10yc3KYbHTs0CADCgbFQQAfiUxgvj2ESgWh0asAHzWxtRnXFYRNNcA6Izt/jdXYejmgnZZobhKjk4fRjcrF9/4mkWD5gkzJrxto6B9F34rPmlGb+4uFmf5wWSyj6khqu1lxsR24nkc2JVT5HRvISWeZE+w1d8YmhJbGCUEBkYjmpjLs12V2UzGxA8o0kHwwd0UgMNxI8r3DiEE9BbVaeUxwf/qv/zuzWzCMomyVAMKLHDh7qdH0TqW9SPpHR9o7GvgLUJKSA=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 31:755j+NuUAaLzyMGLGyHYVfIlBA8wqPyG7IIpvGJMDWTRB6mubPZr7ZrebSoI+QlNj7x5IQwzlu3mdf+HbCv0hqUaT9u/2zJVanKW1nLffw2ChYO36hBtHXGT+EgwE5tXra3FDl8H3ndyVylvcc8TL0tvf2d9vayMxkg7jvI5ODWvvKXats65stdfTEMTxQrFx59pvpnRLg2wpDCbmvYbyA==; 4:XwRqrzo8a8/OQNGpVEUvjy0xY3v5b3BwnWmBnMYRzI/qHPTDCafqkhTMMFX7eK6dGZ24nTHrtwT7Ei3++7vrOJYwkWdKUyZ5blBPGf5DRSf9iqY8RS8/YImoaoPcezeU1JAHcfSaSgrmbuACPpFYhlL11A9OsUhQXhM8L4/34BTweW/QAT4Ful1gFJJttWvmFZ/DCYPrGEI8VzygyTNLsciAWox1U0IOuMcfCy0bDlvZdt0J3ZE/8R/kqztVJlF46AUT5cTf1JKxofbBLt1OIsNooPZosUrXTS0lPlI8woQtpJHD0vlY7LKP8mTJdPBSGfqncVBlvN8PEqUOlJClpudcvbzcpoe8Cd7wkv4Lzg1jUdLvIPElBxdKBeOlwTkV8iXJ1rXbTwj49ChJV329wXPlmlWm1trHZCiusoJkDtMfswSBr/WAe4O04b/tzq6E1ps4ipV1asWQXeoMzGlx03mpV+KDPZGR3bHv7fpjeiU=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(788757137089); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1631; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1631; 
X-Forefront-PRVS: 001968DD50
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(13464003)(199003)(377454003)(189002)(81156014)(9686002)(7736002)(8676002)(68736007)(7846002)(230783001)(44716002)(97736004)(189998001)(81166006)(116806002)(62236002)(5001770100001)(50226002)(50466002)(101416001)(19580395003)(106356001)(66066001)(15975445007)(61296003)(76176999)(42186005)(14496001)(33646002)(1556002)(3846002)(44736004)(92566002)(86362001)(47776003)(1456003)(50986999)(6116002)(77096005)(305945005)(4326007)(2906002)(19580405001)(23676002)(84392002)(81686999)(105586002)(586003)(81816999)(230700001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1631; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIxNjMxOzIzOjNyMStIWW1haUZDRlI5Sis3WFdjWTRXLzJt?= =?utf-8?B?TTFGMU9YMnJIM05KM3RVQ3gzWE1ZOHMvQzhBSzQ1N1JNbkRwckl2RTZsTE1l?= =?utf-8?B?eFBnT1NFT0NKa281dmZYMGdJamIzcVFJK0l6Z2Z0WDYwVEpudmx5WHV3VUJU?= =?utf-8?B?NW1FeUU4Q3pucDV4cFNTNFdrcjdiZC9wdFY4d2x1VGtyTW5UZDMveVN6NlFS?= =?utf-8?B?REpaeXp3V0xHUkRNYm1uVSs3ckRPalZHZFNkODlETEFyWTJzUFJOazBDeEZM?= =?utf-8?B?elNmN2k4TTRtQXFRYmZVdFZySTJlNlZnZmRzd0hrdXU1aTJXdGlLcFQ3b21s?= =?utf-8?B?eitrNXZiTWltdjZLWXZiaUN2NDNHbmNlSTVWbER4RlBPRFEwVUdKeTNjbTZE?= =?utf-8?B?clBiTFB4M2tpbGZnQlBQSGhvN3NSWDhYaDVGQ0cyaG1EQlQyQmpXUGN5OUNX?= =?utf-8?B?WTBVNTNLQmozK1lVYURHNm1uYVN0Vzl1M2ZpaUdmY3QwS1kwK2lreGdXdUR1?= =?utf-8?B?NFpkbHkzSC83emdzTThrdVRUUUxZbWJKejhWRmpNTHhzQjBRaGxuRnhTbmZW?= =?utf-8?B?dWJDNmFJbjhpMWd0KzZqSlYvb2lkbGIrUnVUYzMrS2Z0ZThVcmgzbmtzZSt0?= =?utf-8?B?UnVZOTEyOS9kK0t1V1QvMUw0TWZlWXpmRmFWMnNpMU1BQXZnRENic3VpUCtk?= =?utf-8?B?V01wcUZzSmVpVEhrZUMzbzdTUUgyejg2SlpCVE80V25lQkdrWndCZFdaVm1J?= =?utf-8?B?ZnNkaC9UVFYwSktyN0FTcWRqemdJbUJxR29oWHlmS1JPS0lkNnRuWUdxZ1Vw?= =?utf-8?B?UDFLS0dSd0RqcUdSVnZnM1Z6U3J0VEhKYkw2KzNFRHA3bksvdTIrUk9UOGxL?= =?utf-8?B?VndUTVMwNDdOVGRHNUlsdjZyTFN1YjVFcklaL0Q1akZMMXAyT3VEbEZwSkM0?= =?utf-8?B?NnE2REVVc3A5eit4SFMyeWRuT3Uvc0JoMGE2amkvOE5jZEJLdkl1QkxMMXM0?= =?utf-8?B?R1AxbWI0N2duM3cyT3dPVWZFQjdHa3Vqa0diclFLcE5QUmVhSVZKdURKVXdX?= =?utf-8?B?NFp3UGFGTVFHb01qRXdMQzJ4dm9PaHlEVWZrYmMvYjl5REdHQWF1NlJ2Zysx?= =?utf-8?B?TnlVcVFhTUtBdkZYQXlHUTQyYnBoRjlBcHZqdDVQb0l6czlnVkJlWHRlb0Vk?= =?utf-8?B?RmJ0SnRFUlVaTXFpSW5mMlJBVDUzVDFxMTltRHFqcjFXK1BPdUhIbHc3a1FE?= =?utf-8?B?dWJVSUhyMmMyNHJzMjN2NDlVTGR1M0lVZTRzTXhSb3Y4UHFpTlpobnVyY0dM?= =?utf-8?B?TmhnOXJ6alRRVWR2MGN1UWdvTnYyVnFFbHVOOEdXWDQxdnpzeHhOTVI1eDFX?= =?utf-8?B?ZTQ1L2FBcVVqOWE2TTBJQzRINk5rL3doTWFhVWNZMEIrcXNsM2NJRkx0RU1x?= =?utf-8?B?Tmx2RXFGa3NXSFlybkNteHpJVTg3Zk5HUkkzZWFNZ0djWWdOVjZUVVZKbXhO?= =?utf-8?B?Zk9OeWl4RjJ6b1V2MWJMR1BQbFN3MzBvcmhFWjlQSlVNUXJscTZBb1UwRktY?= =?utf-8?B?TjlQcElhYkFmY21IVWR4ei9zQlAxalQ0Z3kralp5cytOeFZWQ2dVV2d4bm51?= =?utf-8?B?ZmVXUDFKUnNsQ3VHc3ZhbmhMUVNDV1ZZeSttSys1ZksyR1ZXeHczcjNwdno2?= =?utf-8?B?NVp1VWRrSkZQeUtqY3YrM1J2bTd0U0M3cUd2a3FRdnBnUGtIb3hWcU9WSW45?= =?utf-8?B?SnFZL1RYR0YwZDBHTm5HcFJuQjBCSWhKOXBXamordldrT1A2UWRuYjl6dTBi?= =?utf-8?B?eUdnR2hKUXF0emJZUkxSd3NvUHRUSHdKQ2phOHB4bVJMVGpDOVAxczltcDV6?= =?utf-8?Q?l1RVGhj4e34qav1fSV7wW/vKaoEffo/U?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 6:QTQ3BCjjb5UYaaHJA2XdbZNraTHQI53s7q9wzXwzV3MmdnQegn4JaZUTPAoN4kIpcvw8pFSVIFo/663e+Bm1GpFKp716i8pveU2+TBgSadR2rwJYbdMcVxWT/sJTFQs92gBfXSm7SuyENWD8+J1uYFffnQCbwak2fPEpheMPfF6w5AZ2/1UOlICXq/782TL8XJinIte6pXnQq0/8MDlVsdEe77KsuDB53hx0NkS6sJgFKIHbOigz0/hRVzdoHTCKUdxPPFpb8TKDvHkEgN+2Ky4kPH4trgmDxH9XhHEZ1xg=; 5:gowqB507g0mLsiQBn5O/jFUkG4cJjprBTftaG9UwgYaj/2NFHL2figrOKRQComz9Liz248+ge0XtZN8mZgjIx43uZH5LrBfgKDotdzhIUU1u0vvciTveapVDACT5bb9KtP+ekQWIT4POxBYh5rsF8w==; 24:SEDzAFKaarAlZFHzHmtfoGn3bGPbR8hmwplRN21IrDrOM+q4mYiH0n58bcL1qYVAd1kqthpZpz1BYKRNMDTMuLf0R/8ud5sBrWNnUgWiGs8=; 7:90IYJYtxGqkobzrl9NR90wV5lx1GLEkYwCclRmKKfrizhQE9+dOTYxG8yHoLUxuRZFleSLozEgXwIP8POJxVdFmUOd1Tj4tGOXEdzF+X+G8qGM65oslOyBZuSqFYTZn6CZnGclc8pUKRc9dsR1ng0ppDJ9UbYVLILU5PhP8s4AfoS1zH3+uAB7q1XlQxS4kRFLTKcVKDmywLVnQpS8HgwklmAMBE3cX7a7XAKAP4P8cvRhltdH6Rha5K4m/kkEDn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2016 11:48:15.1213 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1631
Archived-At: 
Cc: General Area Review Team , draft-ietf-netconf-restconf.all@ietf.org, ietf@ietf.org, Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Jul 2016 11:48:24 -0000

Robert

Picking up on the point about terminating the connection when a
certificate validation fails,  this is a straight lift from 'Netconf
over TLS', RFC7589, where the reference is also in Section 4 which makes
it clear (to me:-) that the reference is to how the connection is
terminated, as per RFC5246 s.7.2.1, and nothing to do with the
certificate validation, which is as per RFC5280.

Tom Petch

----- Original Message -----
From: "Robert Sparks" 
To: "Andy Bierman" 
Cc: "General Area Review Team" ;
; ; "Netconf"

Sent: Friday, July 29, 2016 9:47 PM
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15


>
>
> On 7/29/16 3:36 PM, Andy Bierman wrote:
> > Hi,
> >
> > I will add this review to the list.
> > A new version in in progress.
> > Some comments inline
> >
> >
> > On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks  > > wrote:
> >
> >     I am the assigned Gen-ART reviewer for this draft. The General
Area
> >     Review Team (Gen-ART) reviews all IETF documents being processed
> >     by the IESG for the IETF Chair.  Please treat these comments
just
> >     like any other last call comments.
> >
> >     For more information, please see the FAQ at
> >
> >     .
> >
> >     Document: draft-ietf-netconf-restconf-15
> >     Reviewer: Robert Sparks
> >     Review Date: 28Jul2016
> >     IETF LC End Date: 3Aug2016
> >     IESG Telechat date: not yet scheduled
> >
> >     Summary:
> >
> >     Major issues:
> >
> >     * I am not finding any discussion in the Security Considerations
> >     or in the text around what a server's options are if a client is
> >     asking it to keep more state than it is willing or capable of
> >     holding. The possible values of the "depth" query parameter
> >     (particularly "unbounded") points out that a misconfigured or
> >     compromised client might start creating arbitrarily deep trees.
> >     Should a server have the ability to say no?
> >
> >
> >
> > I guess we need more text somewhere explaining the "depth" parameter
is
> > a retrieval filter.
> I got that. It's existence, however, caused me to think about the fact
> that what is stored at the server can be arbitrarily deep. Clients
using
> POST can build trees that are arbitrarily deep, with bits at the node
> that are arbitrarily large (subject to the constraints the YANG models
> put on the node). There should be some discussion acknowledging that
> this can happen, and discussion of what the server can do if some
client
> starts asking it to store more than it is willing to store.
> > It is not used to create anything in the server.
> > The server does not maintain any state except during the processing
of
> > the retrieval request
> >
> >
> >     * The third paragraph of 3.7 paraphrases to "SHOULD NOT delete
> >     more than one instance unless a proprietary query parameter says
> >     it's ok". This isn't really helpful in a specification.
> >     Proprietary things are proprietary. The SHOULD NOT already
allows
> >     proprietary things to do something different without
trainwrecking
> >     the protocol. Please just delete the 2nd and 3rd sentence from
the
> >     paragraph.
> >
> >
> > OK
> >
> >
> >     * Section 2.3 says "If X.509 certificate path validation fails
and
> >     the presented X.509 certificate does not match a locally
> >     configured certificate fingerprint, the connection MUST be
> >     terminated as defined in [RFC5246]." RFC5246 doesn't really talk
> >     about certificate validation, and it certainly doesn't say "the
> >     connection MUST be terminated" when certificates fail to
validate.
> >     What are you trying to point to in RFC5246 here? Should you be
> >     pointing somewhere else? (It's perfectly reasonable for the
> >     document to reference RFC5246, and it does so elsewhere without
> >     problem).
> >
> >
> >
> > Please suggest replacement text if we are citing the wrong RFC.
> > I will ask Kent to look into this issue
> >
> >
> >     Minor issues:
> >
> >     * "A server MUST support XML or JSON encoding." is ambiguous.
(2nd
> >     paragraph of 5.2). Did you mean the server MUST support at least
> >     one of XML or JSON but not necessarily both? I think you really
> >     intended that the server support BOTH types of encoding.
> >
> >
> > No -- it will be clarified that the server must support at least 1
of
> > the 2
> >
> >
> >     * I _think_ I can infer that PUT can't be used with datastore
> >     resources. Section 3.4 only speaks of POST and PATCH. Section
4.5
> >     speaks about "target data resource" and is silent about
datastore
> >     resources. If I've understood the intent, please be explicit
about
> >     datastore resources in 4.5. If I've misunderstood then more
> >     clarity is needed in both 3.4 and 4.5.
> >
> >
> > The  next draft will be clarified to allow PUT on a datastore
resource
> Hrmm - that makes me less comfortable that you are actually aligned
with
> 7231. It may just be that you need to be more precise with your
> description, but per 7231, PUT never creates resources - it can create
> or replace the state of a resource.
> >
> >     * In 3.5.3.1 you restrict identifiers with "MUST NOT start with
> >     'xml' (or any case variant of that string). Please call out why
> >     (or point to an existing document that explains why).
> >
> >
> > OK
> >
> >
> >     * The text in 5.3 about access control interacting with caching
> >     (added based on my early review I think) doesn't mesh well with
> >     paragraph 3 of section 5.5. There you tell the client to use
Etag
> >     and Last-Modified, but in 5.3 you say it won't work reliably
when
> >     access permissions change. At the very least 5.5 should point
back
> >     into the paragraph in 5.3.
> >
> >     Nits/editorial comments:
> >
> >     * Introduction, 4th paragraph - please change "MAY provide" to
> >     "provides". Section 3.6 explains the cases where there is choice
> >     in what to provide.
> >
> >
> >     * Section 2.3 paragraphs 1 and 2. There is edit-itis here left
(I
> >     suspect) from working in matching fingerprints. Consider
combining
> >     and simplifying these two paragraphs after improving the
reference
> >     issue called out above.
> >
> >     * Section 4 says "Access control mechanisms MUST be used to
> >     limit..." This is not a good use of a 2119 MUST. I suggest
> >     replacing "MUST be" with "are". The subsequent text already
> >     captures the actual normative requirements on the server.
> >
> >     * Section 12 says "this protocol SHOULD be implemented
carefully".
> >     That is not a good use of a 2119 SHOULD. It is not a protocol
> >     requirement. I suggest reformulating this into something like
> >     "There are many patterns of attack that have been observed
through
> >     operational practice with existing management interfaces. It
would
> >     be wise for implementers to research them, and take them into
> >     account when implementing this protocol." It would be far better
> >     to provide a pointer to where the implementer should start this
> >     research.
> >
> >     * (micronit) Lots of examples are internally inconsistent wrt
> >     dates. For instance, look at the 200 OK in section 3.3.3 - it
says
> >     that back in 2012, a server returned something talking about a
> >     library versioned in 2016.
> >
> >
> >
> > Andy
> >
>
>


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


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


From nobody Sat Jul 30 11:52:29 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7A212D75B for ; Sat, 30 Jul 2016 11:52:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5y2IZ3Lpk2g for ; Sat, 30 Jul 2016 11:52:26 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B349512D0CB for ; Sat, 30 Jul 2016 11:52:25 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id s189so75221694vkh.1 for ; Sat, 30 Jul 2016 11:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oJ2ntS5mT8QjEU0uQSxhlSjbBn36kpE+fVEq8xPMqTI=; b=IYzlIWRAY5isf93xQUd8AYnl5pbkaTe4kJ0bkfEhFzNsK/6wAMHHZme9COuwjiOrGw 4USjHsX4/rLGUt7U0lPjlEuu4SB1k8cLiXJsTAhHbi+pgFW34xX3mC1fEXVX7ZuWhMQw kb+Ve7YGGrFUuvgG8eaVB+2vKTQ0vK7oum/GWEXFWfuQ9eWXu8OVKCmHS1sjKyH+qMd+ +i13/dfU+n8DXRfukCLKPb2+quzs+DKeXraELpMhgsbcTQf4imNPlmxotFK+X7CQd8x2 Z3ABqIVkRNRAE9wYEzeK8m7+G7QaXaa+P0VNmxzQ12CBktUsHsH7M2JTXc1FdCUVKVSM WN9Q==
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; bh=oJ2ntS5mT8QjEU0uQSxhlSjbBn36kpE+fVEq8xPMqTI=; b=XMpKR5w4glDFIW8v2Fg508g9yZQsgmEPSXnUT1cnlsZbXweFbKIjo+6/Sl1FIluJBu 7yL2x3hpFL6X4PS0HuMy8HInc10/RpPdWFAyGt/zy7Q+gw3HIEjEJyzr6oAbnNxfRNhX 3xUT31baquiepiSxO1qGsuAngoc78m1FhFENo6w/QuDAfi9jrY1HwEPflOqzHPf/K2vw 0bFLLPxaCIAvEP0ys7ushhIoWjovXgx1HEbsSa3iRdPTcHB1cRqN0Ka47L8QLzEmxA4z shekOZnHuE6bA7PF35S9AfyQrk+W1gnxlHTAYr+FK7ULi40CUHYcrC2cfHeOGAJhN21b QaLg==
X-Gm-Message-State: AEkoouvCqZypevTyJ3sqdzJskEwD2imTd1CGX/jfrrkeWIhMgI7CTgL2Dl8rsFXPbA13wYLb189DftWO/EYeNA==
X-Received: by 10.31.244.69 with SMTP id s66mr12801754vkh.121.1469904744546; Sat, 30 Jul 2016 11:52:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Sat, 30 Jul 2016 11:52:23 -0700 (PDT)
In-Reply-To: <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>
From: Andy Bierman 
Date: Sat, 30 Jul 2016 11:52:23 -0700
Message-ID: 
To: Balazs Lengyel 
Content-Type: multipart/alternative; boundary=94eb2c125e18271d4c0538dedebe
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Jul 2016 18:52:28 -0000

--94eb2c125e18271d4c0538dedebe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I strongly object to changing a vague MAY about deleting an NP container
after the last child has been deleted into several MUST requirements.

I propose this text instead:

OLD:


   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.


NEW:


   If a container does not have a "presence" statement and the container
instance
   does not have any child node instances, the NETCONF server MAY delete th=
e
   container. If the server does delete a container instance in this case,
it MUST
   re-create the container instance if a client  request
attempts to create
   a child node instance within this container.




Andy


On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel  wrote:

> Hello,
>
> We seem to have fundamental differences whether NP-containers exist/don't
> exist or if this question is even valid.  I hope we can agree that as
> NP-containers are meaningless themselves they MUST NOT influence Netconf
> operations or model validation. (Which is a slight violation of
> Netconf-6241, which we should accept.)
>
> So I propose the following errata to rfc6020bis.
>
> As for non-presence containers the presence of the container node with no
> child nodes is
> semantically equivalent to the absence of the container node,
> configuration operations or
> model validation should never fail due to the existence or non-existence
> of a non-presence containers. Specifically:
>
> - an   create operation for a non-presence container MUST
> succeed even if the container already exists.
> - an   delete operation for a non-presence container MUST
> succeed even if the container does not exist.
> - an   operation with default-operation=3Dnone MUST succeed
> even if one or more  non-presence containers do not exist.
>
> Separately
> - a must statement defined as direct substatement of a non-presence
> container SHALL be evaluated as part of model validation if and only if o=
ne
> or more child data nodes exist in the instance data or if there is a leaf
> or leaf-list child with a default value. As non-presence containers are
> only used for organizing the hierarchy they SHOULD NOT have any must
> substatements.
> IMO the above rules remove ambiguity and follow the current philosophy of
> RFC6020bis.
> If we have a basic agreement I can formulate the text correctly.
>
> I don't know whether similar updates are needed for RestConf.
> regards Balazs
>
> PS. I still believe introducing NP containers was a mistake, however they
> are here to stay.
>
> On 2016-07-21 09:17, Jan Lindblad wrote:
>
> Xiang,
>
> Are you saying that since a NP-container is merely a structure node, not
> config in any way, so creating/deleting it explicitly (and repeatedly) is
> equivalent to a =E2=80=9Cno-op=E2=80=9D that will always succeed because =
doing so has no
> effect on the server=E2=80=99s config in any way?
>
>
> That's correct. "Creating" an object with zero bits of information is a
> no-op.
>
> If the sever has the following example config:
> 
>      
> 
>
>
> If a client issues an edit-config with:
> < mycontainer operation=3D"delete">
>
> The server returns =E2=80=9Cok=E2=80=9D,
>
> If then again  the client attempts:
>
> < mycontainer operation=3D"delete">
>
> The server should still return  =E2=80=9Cok=E2=80=9D?
>
>
> Yes, that's correct in my opinion. It's a consequence of the NP container
> nature as defined in the current RFC6020/YANG 1.0 and bis.
>
>
> If so I think this is confusing. I think it would make more sense in the
> latter case if the server returns =E2=80=9C"data-missing=E2=80=9D error.
>
>
> This is logical if you think of NP containers as path prefixes, and not a=
s
> objects with information content. If you accept that an NP container has
> zero bits of information, how would the server even know whether the
> container exists or not? Not by looking in a database, for sure.
>
> P containers have a single bit of information, so they can be created, an=
d
> the creation event/existence remembered by the server. Not so for
> NP-containers.
>
> I understand we may advise a client not do so, but since  RFC6020bis does
> not forbid this, and it is also a perfectly valid , so I am
> sure people will try it.
>
>
> Yes. And it works today and is harmless.
>
> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on
> the subject, but I believe the interpretation I and others have of NP
> container behavior in RFC 6020 is consistent, implementable and highly
> useful.
>
> /jan
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--94eb2c125e18271d4c0538dedebe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I strongly object to changing a vag=
ue MAY about deleting an NP container
after the last child has be=
en deleted into several MUST requirements.

I propo=
se this text instead:

OLD:


=C2=A0 =C2=A0If a container does not have a "pre=
sence" statement and the last
=C2=A0 =C2=A0child node is del=
eted, the NETCONF server MAY delete the container.


NEW:


=C2=A0 =
=C2=A0If a container does not have a "presence" statement and the=
 container instance
=C2=A0 =C2=A0does not have any child node ins=
tances, the NETCONF server MAY delete the
=C2=A0 =C2=A0container.=
 If the server does delete a container instance in this case, it MUST
=

=C2=A0 =C2=A0re-create the container instance if a client <ed=
it-config> request attempts to create
=C2=A0 =C2=A0a child nod=
e instance within this container.


<=
br>

Andy


On Fri, Jul 22, 2016 at 3:13 AM, Balaz=
s Lengyel <balazs.lengyel@ericsson.com> wrote:
=


 =20
   =20
 =20
  

    
Hello, 

    

    
We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.=C2=A0 I hope=
 we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation. (Which is a slight
      violation of Netconf-6241, which we should accept.)

    

    
So I propose the following errata to rfc6020bis.

    
As for non-presence containers the presence of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:

    
- an <edit-config>=C2=A0 create operation for a non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>=C2=A0 delete operation for a non-presence
      container MUST succeed even if the container does not exist.=C2=A0 
      - an <edit-config>=C2=A0 operation with default-operation=3Dnon=
e
      MUST succeed even if one or more=C2=A0 non-presence containers do not
      exist. 

    

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for
      organizing the hierarchy they SHOULD NOT have any must
      substatements.

    IMO the above rules remove ambiguity and follow the current
    philosophy of=C2=A0 RFC6020bis. 

    If we have a basic agreement I can formulate the text correctly.

    

    I don't know whether similar updates are needed for RestConf.

    regards Balazs

    

    PS. I still believe introducing NP containers was a mistake, however
    they are here to stay.=C2=A0 

    

    
On 2016-07-21 09:17, Jan Lindblad
      wrote:

    

    

     =20
      Xiang,
      


      

      

        

          

            

              

                
Are
                    you saying that since a NP-container is merely a
                    structure node, not config in any way, so
                    creating/deleting it explicitly (and repeatedly) is
                    equivalent to a =E2=80=9Cno-op=E2=80=9D that will alway=
s succeed
                    because doing so has no effect on the server=E2=80=99s
                    config in any way?=C2=A0

              

            

          

          


          

          
That's correct. "Creating" an object with zero=
 bits of
            information is a no-op.

          


          

          

            

              

              
If the
                  sever has the following example config:

              
<mycontainer><=
/u>

              
=C2=A0=C2=A0=C2=A0
                  =C2=A0<child =C2=A0... bla..bla=E2=80=A6configs>=


              
</mycontainer>=


              
=C2=A0
              
=C2=A0
              
If a
                  client issues an edit-config with:
              
<=C2=A0mycontaine=
r=C2=A0operation=3D"delete">
              
=C2=A0
              
The
                  server returns =E2=80=9Cok=E2=80=9D,=


              
=C2=A0
              
If then
                  again =C2=A0the client attempts:
              
=C2=A0
              
<=C2=A0mycontaine=
r=C2=A0operation=3D"delete">
              
=C2=A0
              
The
                  server should still return =C2=A0=E2=80=9Cok=E2=80=9D?

            

          

          


          

          
Yes, that's correct in my opinion. It's a consequenc=
e of
            the NP container nature as defined in the current
            RFC6020/YANG 1.0 and bis.

          
=C2=A0

          

            

              
If so I
                  think this is confusing. I think it would make more
                  sense in the latter case if the server returns =E2=80=9C<=
/span>"data-missing=E2=80=9D error.

            

          

          


          

          
This is logical if you think of NP containers as path
            prefixes, and not as objects with information content. If
            you accept that an NP container has zero bits of
            information, how would the server even know whether the
            container exists or not? Not by looking in a database, for
            sure.

          


          

          
P containers have a single bit of information, so they
            can be created, and the creation event/existence remembered
            by the server. Not so for NP-containers.

          


          

          

            

              
I
                  understand we may advise a client not do so, but since
                  =C2=A0RFC6020bis does not forbid this, and it is also a
                  perfectly valid <edit-config>, so I am sure
                  people will try it.

            

          

          


          

          
Yes. And it works today and is harmless.

          


          

          
It's unfortunate that the YANG 1.0 and 1.1 specs aren=
9;t
            crystal clear on the subject, but I believe the
            interpretation I and others have of NP container behavior in
            RFC 6020 is consistent, implementable and highly useful.

          


          

          
/jan

          


          

        

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  




_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--94eb2c125e18271d4c0538dedebe--


From nobody Sat Jul 30 17:21:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559E512B060 for ; Sat, 30 Jul 2016 17:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlL9zNMRv0KC for ; Sat, 30 Jul 2016 17:21:04 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4A812B057 for ; Sat, 30 Jul 2016 17:21:04 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id w18so151664135oiw.3 for ; Sat, 30 Jul 2016 17:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=NSzAvvOKw9y1lG4XcQ8Lun9EXcttJ2WVNYoALYy7H3g=; b=gg42UoXgPS5CAN3V3d4uJZd4aCebPuJ7hq1G6aCMY5aghSAsHblftD2HYg1e21D/Ua vAnDIA2avdh4iH5DrFAeS5aN5w+pqTYkeIzfcZH0YfItAjw2xu6P8L6+5+MRDOvfN67R UiXzXg0mVWH1QJZmZCZbleBg4NdFUFlTt8+Xi6V7z7KGdaLIDKiePba05VQBfxLqyJci p8ccAzW1MxhEFTl0YX8PbZ39vFGnfNcj8qjISZ8MaXTN5M0AV2Ssxuwx2AzlTZQ3ZQxu zK3an4X5HvKi/9rlg+0+2ivlKK1vwUdp73p4YeJ4mdi2cCF9kWJvogXESAmgSN2F/hNx hiNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NSzAvvOKw9y1lG4XcQ8Lun9EXcttJ2WVNYoALYy7H3g=; b=Pi5OeMNtKUks1opbvf4ZrfgzjhdNwVWsPf3WrQSiQM6o5U3K6w4zmPQD3O/IQxH7Mz YnrMtWCPte1J4Otz+cbuPfaYqHADOxG64TYFBKDx/vBOZYgnC+Xa4sRVPxA8YUs9HTG0 WjAF+LFzw8i4zQrCzyB1Bq9UwetWB4oTba/s/v85GUcy9gsnSdP9hZ6+ll2atT66XmF8 o7+h4mMB6q7TqKSSkLcrQA4iUl2Wa0+Nn6tX63GfKxGLL+E78Iz3hiuhcxRpBg0C1+zH A3DSk4hOBsWLzmdwmPgC7AuKXkNy8ktzvsGgwhSmmp3AePYWLpI3MrLzcq+Bqs54uhA8 4gzA==
X-Gm-Message-State: AEkoousR+fLSOlQXZen5kB2mvtw+Yjdm/q5Zxjw1Id5hCr1eTg63Lc5BxvcSoWzVoqfWew==
X-Received: by 10.157.8.4 with SMTP id 4mr3147602oty.17.1469924463937; Sat, 30 Jul 2016 17:21:03 -0700 (PDT)
Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:c1bf:a325:2670:adda]) by smtp.gmail.com with ESMTPSA id p34sm9949786ota.39.2016.07.30.17.21.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 30 Jul 2016 17:21:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_615700C2-CBC4-4DD1-AE69-9728F9A37C85"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Sat, 30 Jul 2016 17:21:00 -0700
Message-Id: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2016 00:21:07 -0000

--Apple-Mail=_615700C2-CBC4-4DD1-AE69-9728F9A37C85
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Andy,

The thread started because the RFC does not say anything about a create =
of a NP container. It only talked about delete. Can we make the =
(re-)create of the NP container unconditional to whether a delete was =
performed on it. So a tweak to your proposal would be:

OLD:

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

NEW:

   If a container does not have a "presence" statement and the container =
instance
   does not have any child node instances, the NETCONF server MAY delete =
the
   container. It MUST create the container instance if a client =
 request=20
   attempts to create a child node instance within this container.


> On Jul 30, 2016, at 11:52 AM, Andy Bierman  wrote:
>=20
> Hi,
>=20
> I strongly object to changing a vague MAY about deleting an NP =
container
> after the last child has been deleted into several MUST requirements.
>=20
> I propose this text instead:
>=20
> OLD:
>=20
>=20
>    If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container.
>=20
>=20
> NEW:
>=20
>=20
>    If a container does not have a "presence" statement and the =
container instance
>    does not have any child node instances, the NETCONF server MAY =
delete the
>    container. If the server does delete a container instance in this =
case, it MUST
>    re-create the container instance if a client  request =
attempts to create
>    a child node instance within this container.
>=20
>=20
>=20
>=20
> Andy
>=20
>=20
> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel =
> =
wrote:
> Hello,=20
> We seem to have fundamental differences whether NP-containers =
exist/don't exist or if this question is even valid.  I hope we can =
agree that as NP-containers are meaningless themselves they MUST NOT =
influence Netconf operations or model validation. (Which is a slight =
violation of Netconf-6241, which we should accept.)
> So I propose the following errata to rfc6020bis.
>=20
> As for non-presence containers the presence of the container node with =
no child nodes is=20
> semantically equivalent to the absence of the container node, =
configuration operations or=20
> model validation should never fail due to the existence or =
non-existence of a non-presence containers. Specifically:
>=20
> - an   create operation for a non-presence container MUST =
succeed even if the container already exists.=20
> - an   delete operation for a non-presence container MUST =
succeed even if the container does not exist. =20
> - an   operation with default-operation=3Dnone MUST =
succeed even if one or more  non-presence containers do not exist.=20
> Separately
> - a must statement defined as direct substatement of a non-presence =
container SHALL be evaluated as part of model validation if and only if =
one or more child data nodes exist in the instance data or if there is a =
leaf or leaf-list child with a default value. As non-presence containers =
are only used for organizing the hierarchy they SHOULD NOT have any must =
substatements.
>=20
> IMO the above rules remove ambiguity and follow the current philosophy =
of  RFC6020bis.=20
> If we have a basic agreement I can formulate the text correctly.
>=20
> I don't know whether similar updates are needed for RestConf.
> regards Balazs
>=20
> PS. I still believe introducing NP containers was a mistake, however =
they are here to stay. =20
>=20
> On 2016-07-21 09:17, Jan Lindblad wrote:
>> Xiang,
>>=20
>>> Are you saying that since a NP-container is merely a structure node, =
not config in any way, so creating/deleting it explicitly (and =
repeatedly) is equivalent to a =E2=80=9Cno-op=E2=80=9D that will always =
succeed because doing so has no effect on the server=E2=80=99s config in =
any way?=20
>>=20
>> That's correct. "Creating" an object with zero bits of information is =
a no-op.
>>=20
>>> If the sever has the following example config:
>>> 
>>>      
>>> 
>>> =20
>>> =20
>>> If a client issues an edit-config with:
>>> < mycontainer operation=3D"delete">
>>> =20
>>> The server returns =E2=80=9Cok=E2=80=9D,
>>> =20
>>> If then again  the client attempts:
>>> =20
>>> < mycontainer operation=3D"delete">
>>> =20
>>> The server should still return  =E2=80=9Cok=E2=80=9D?
>>=20
>> Yes, that's correct in my opinion. It's a consequence of the NP =
container nature as defined in the current RFC6020/YANG 1.0 and bis.
>> =20
>>> If so I think this is confusing. I think it would make more sense in =
the latter case if the server returns =E2=80=9C"data-missing=E2=80=9D =
error.
>>=20
>> This is logical if you think of NP containers as path prefixes, and =
not as objects with information content. If you accept that an NP =
container has zero bits of information, how would the server even know =
whether the container exists or not? Not by looking in a database, for =
sure.
>>=20
>> P containers have a single bit of information, so they can be =
created, and the creation event/existence remembered by the server. Not =
so for NP-containers.
>>=20
>>> I understand we may advise a client not do so, but since  RFC6020bis =
does not forbid this, and it is also a perfectly valid , so =
I am sure people will try it.
>>=20
>> Yes. And it works today and is harmless.
>>=20
>> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear =
on the subject, but I believe the interpretation I and others have of NP =
container behavior in RFC 6020 is consistent, implementable and highly =
useful.
>>=20
>> /jan
>>=20
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com =20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_615700C2-CBC4-4DD1-AE69-9728F9A37C85
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Andy,

The =
thread started because the RFC does not say anything about a create of a =
NP container. It only talked about delete. Can we make the (re-)create =
of the NP container unconditional to whether a delete was performed on =
it. So a tweak to your proposal would be:

OLD:

   If a =
container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY =
delete the container.

NEW:

   If a container =
does not have a "presence" statement and the container =
instance
   does not have any child node =
instances, the NETCONF server MAY delete the
  =
 container. It MUST create the container instance if a client =
<edit-config> request 
  =
 attempts to create a child node instance within this =
container.


On Jul 30, 2016, at 11:52 AM, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

I strongly object to changing a vague MAY about deleting an =
NP container
after the last child has been deleted =
into several MUST requirements.

I propose this text instead:

OLD:


   If a container does not =
have a "presence" statement and the last
  =
 child node is deleted, the NETCONF server MAY delete the =
container.


NEW:


   If a container does not have a "presence" =
statement and the container instance
  =
 does not have any child node instances, the NETCONF server MAY =
delete the
   container. If the server =
does delete a container instance in this case, it MUST
   re-create the container instance if a client =
<edit-config> request attempts to create
 =
  a child node instance within this container.




Andy


On Fri, =
Jul 22, 2016 at 3:13 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> =
wrote:

 =20
   =20
 =20
  
Hello, 

    
We seem to have fundamental differences whether =
NP-containers
      exist/don't exist or if this question is even valid.  I hope =
we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation. (Which is a slight
      violation of Netconf-6241, which we should accept.)

    
So I propose the following errata to =
rfc6020bis.
As for non-presence containers the presence =
of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:
- an <edit-config>  create operation for a =
non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>  delete operation for a non-presence
      container MUST succeed even if the container does not exist.  =


      - an <edit-config>  operation with =
default-operation=3Dnone
      MUST succeed even if one or more  non-presence containers do =
not
      exist. 

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for
      organizing the hierarchy they SHOULD NOT have any must
      substatements.

    IMO the above rules remove ambiguity and follow the current
    philosophy of  RFC6020bis. 

    If we have a basic agreement I can formulate the text correctly.

    

    I don't know whether similar updates are needed for RestConf.

    regards Balazs

    

    PS. I still believe introducing NP containers was a mistake, however
    they are here to stay.  

    

    
On 2016-07-21 09:17, Jan Lindblad
      wrote:

    

    

     =20
      Xiang,
      


      

      

        

          

            

              

                
Are
                    you saying that since a NP-container is merely a
                    structure node, not config in any way, so
                    creating/deleting it explicitly (and repeatedly) is
                    equivalent to a =E2=80=9Cno-op=E2=80=9D that will =
always succeed
                    because doing so has no effect on the server=E2=80=99s=

                    config in any way? 

              

            

          

          


          

          
That's correct. "Creating" an object with zero =
bits of
            information is a no-op.

          


          

          

            

              

              
If the
                  sever has the following example config:

              
<mycontainer>

              
   
                   <child  ... bla..bla=E2=80=A6configs>

              
</mycontainer>

              
 

              
 

              
If a
                  client issues an edit-config with:

              
< mycontainer operation=3D"delete">

              
 

              
The
                  server returns =E2=80=9Cok=E2=80=9D,

              
 

              
If then
                  again  the client attempts:

              
 

              
< mycontainer operation=3D"delete">

              
 

              
The
                  server should still return =
 =E2=80=9Cok=E2=80=9D?

            

          

          


          

          
Yes, that's correct in my opinion. It's a =
consequence of
            the NP container nature as defined in the current
            RFC6020/YANG 1.0 and bis.

          
 

          

            

              
If so I
                  think this is confusing. I think it would make more
                  sense in the latter case if the server returns =
=E2=80=9C"data-missing=E2=80=9D =
error.

            

          

          


          

          
This is logical if you think of NP containers =
as path
            prefixes, and not as objects with information content. If
            you accept that an NP container has zero bits of
            information, how would the server even know whether the
            container exists or not? Not by looking in a database, for
            sure.

          


          

          
P containers have a single bit of information, =
so they
            can be created, and the creation event/existence remembered
            by the server. Not so for NP-containers.

          


          

          

            

              
I
                  understand we may advise a client not do so, but since
                   RFC6020bis does not forbid this, and it is also =
a
                  perfectly valid <edit-config>, so I am sure
                  people will try it.

            

          

          


          

          
Yes. And it works today and is harmless.

          


          

          
It's unfortunate that the YANG 1.0 and 1.1 =
specs aren't
            crystal clear on the subject, but I believe the
            interpretation I and others have of NP container behavior in
            RFC 6020 is consistent, implementable and highly =
useful.

          


          

          
/jan

          


          

        

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  




_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf




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



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_615700C2-CBC4-4DD1-AE69-9728F9A37C85--


From nobody Sat Jul 30 17:31:20 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16B112D104 for ; Sat, 30 Jul 2016 17:31:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLl1gHrGmL_m for ; Sat, 30 Jul 2016 17:31:16 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF84712B060 for ; Sat, 30 Jul 2016 17:31:15 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id j59so84929481uaj.3 for ; Sat, 30 Jul 2016 17:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZsjLq6pW72TAiQ2vfaxzNEsHEO3z6RnYElZjYCKviYA=; b=kG5WFVmAL9dsr0jJXqYqENw2cHCjGU/rKbixmHL39DltOgc8FJQVO/3kRU74dfw/dF wpg5oS7He+r/0ZfWmJQi/oB5E/2PX3mRWk7oXwiHspy1n5bBH0MP6gW8BK/3Xd5TgA/F O0SF1a+ar67TJKcVH6ofBhHAX/wj1wmMPy0C04xEUcUxT/fjlczrlmdAgLIFuOeDJ+5i uUZUJEymN48k84W1W6xYBwllMR4w8yzxAsdfPyHIVNjGoe3eCSLqvrpCiVa6an6iHsS0 epYx3C6RiSs4n0pzYg4QvDDFtosBLv1vaSgJqXLld9OmHtyT0GcI9mdceAO/6voKPU7L 7iyQ==
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; bh=ZsjLq6pW72TAiQ2vfaxzNEsHEO3z6RnYElZjYCKviYA=; b=ZI19NFvP5G+mxfpuERfb4v6rZrPP51Zn49DslZAzoSIzZPp/cG2mMDmLopGgJJybdM jNT0OfD1j+b6FC+irulQtg4uIrsX4bLAMTD0Okb0VbvMC1uFL7qEbEGEH1kM9Q2lgAE9 TI1v/AgITlUjM03Cf+rbn9E40TJ3i3/5LY/0N7tO1SHwC9fWuL5QyJ8XO4mozAt80Flw bW5a2PzGg85XZJfvpB1Dcuof4qH/ELjDyPDDjc12xIUrn4BXq1niPaBIz6igN6NR1B5+ 9ebAvYZhdBdA1Znj78wNak3i5/jaIdOSoegSe8a+LAOM9Y8Z3BsaDPHrdsfHhzMHqD0/ FAdA==
X-Gm-Message-State: AEkoouuG/Gd70aS2Mvi8S0RtnFHYoe1cIUE6HrOS3XbLO71VpCcNOV4gTmDE3CZVfZtZjTOUwGGkeZCRfZENdA==
X-Received: by 10.176.69.210 with SMTP id u76mr19117376uau.16.1469925074991; Sat, 30 Jul 2016 17:31:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Sat, 30 Jul 2016 17:31:14 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>  
From: Andy Bierman 
Date: Sat, 30 Jul 2016 17:31:14 -0700
Message-ID: 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=94eb2c11c304f115510538e399a4
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2016 00:31:19 -0000

--94eb2c11c304f115510538e399a4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Andy,
>
> The thread started because the RFC does not say anything about a create o=
f
> a NP container. It only talked about delete. Can we make the (re-)create =
of
> the NP container unconditional to whether a delete was performed on it. S=
o
> a tweak to your proposal would be:
>
>
The only reason that example did not work is because the server deleted the
NP containers
after the client created them.  If the server does not delete the
containers then
the 2nd RPC will not fail.

This can also be completely avoided by using the default (merge).
Since the client has to explicitly pick default-operation=3Dnone,
it better know what it is doing.  This is the same issue as a default leaf
and the create operation.  Nothing special about NP containers.

The  for "create" will fail if the leaf already exists
and the "delete" will fail if the value is not there (just a default).
The work-around?  Use merge and remove, not create and delete.
IMO the same logic applies here.


Andy




OLD:
>
>    If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container.
>
> NEW:
>
>    If a container does not have a "presence" statement and the container
> instance
>    does not have any child node instances, the NETCONF server MAY delete
> the
>    container. It MUST create the container instance if a client
>  request
>    attempts to create a child node instance within this container.
>
>
> On Jul 30, 2016, at 11:52 AM, Andy Bierman  wrote:
>
> Hi,
>
> I strongly object to changing a vague MAY about deleting an NP container
> after the last child has been deleted into several MUST requirements.
>
> I propose this text instead:
>
> OLD:
>
>
>    If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container.
>
>
> NEW:
>
>
>    If a container does not have a "presence" statement and the container
> instance
>    does not have any child node instances, the NETCONF server MAY delete
> the
>    container. If the server does delete a container instance in this case=
,
> it MUST
>    re-create the container instance if a client  request
> attempts to create
>    a child node instance within this container.
>
>
>
>
> Andy
>
>
> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
>
>> Hello,
>>
>> We seem to have fundamental differences whether NP-containers exist/don'=
t
>> exist or if this question is even valid.  I hope we can agree that as
>> NP-containers are meaningless themselves they MUST NOT influence Netconf
>> operations or model validation. (Which is a slight violation of
>> Netconf-6241, which we should accept.)
>>
>> So I propose the following errata to rfc6020bis.
>>
>> As for non-presence containers the presence of the container node with n=
o
>> child nodes is
>> semantically equivalent to the absence of the container node,
>> configuration operations or
>> model validation should never fail due to the existence or non-existence
>> of a non-presence containers. Specifically:
>>
>> - an   create operation for a non-presence container MUST
>> succeed even if the container already exists.
>> - an   delete operation for a non-presence container MUST
>> succeed even if the container does not exist.
>> - an   operation with default-operation=3Dnone MUST succeed
>> even if one or more  non-presence containers do not exist.
>>
>> Separately
>> - a must statement defined as direct substatement of a non-presence
>> container SHALL be evaluated as part of model validation if and only if =
one
>> or more child data nodes exist in the instance data or if there is a lea=
f
>> or leaf-list child with a default value. As non-presence containers are
>> only used for organizing the hierarchy they SHOULD NOT have any must
>> substatements.
>> IMO the above rules remove ambiguity and follow the current philosophy
>> of  RFC6020bis.
>> If we have a basic agreement I can formulate the text correctly.
>>
>> I don't know whether similar updates are needed for RestConf.
>> regards Balazs
>>
>> PS. I still believe introducing NP containers was a mistake, however the=
y
>> are here to stay.
>>
>> On 2016-07-21 09:17, Jan Lindblad wrote:
>>
>> Xiang,
>>
>> Are you saying that since a NP-container is merely a structure node, not
>> config in any way, so creating/deleting it explicitly (and repeatedly) i=
s
>> equivalent to a =E2=80=9Cno-op=E2=80=9D that will always succeed because=
 doing so has no
>> effect on the server=E2=80=99s config in any way?
>>
>>
>> That's correct. "Creating" an object with zero bits of information is a
>> no-op.
>>
>> If the sever has the following example config:
>> 
>>      
>> 
>>
>>
>> If a client issues an edit-config with:
>> < mycontainer operation=3D"delete">
>>
>> The server returns =E2=80=9Cok=E2=80=9D,
>>
>> If then again  the client attempts:
>>
>> < mycontainer operation=3D"delete">
>>
>> The server should still return  =E2=80=9Cok=E2=80=9D?
>>
>>
>> Yes, that's correct in my opinion. It's a consequence of the NP containe=
r
>> nature as defined in the current RFC6020/YANG 1.0 and bis.
>>
>>
>> If so I think this is confusing. I think it would make more sense in the
>> latter case if the server returns =E2=80=9C"data-missing=E2=80=9D error.
>>
>>
>> This is logical if you think of NP containers as path prefixes, and not
>> as objects with information content. If you accept that an NP container =
has
>> zero bits of information, how would the server even know whether the
>> container exists or not? Not by looking in a database, for sure.
>>
>> P containers have a single bit of information, so they can be created,
>> and the creation event/existence remembered by the server. Not so for
>> NP-containers.
>>
>> I understand we may advise a client not do so, but since  RFC6020bis doe=
s
>> not forbid this, and it is also a perfectly valid , so I am
>> sure people will try it.
>>
>>
>> Yes. And it works today and is harmless.
>>
>> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on
>> the subject, but I believe the interpretation I and others have of NP
>> container behavior in RFC 6020 is consistent, implementable and highly
>> useful.
>>
>> /jan
>>
>>
>> --
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
>

--94eb2c11c304f115510538e399a4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani =
<mjethanand=
ani@gmail.com> wrote:
Andy,

The thread started =
because the RFC does not say anything about a create of a NP container. It =
only talked about delete. Can we make the (re-)create of the NP container u=
nconditional to whether a delete was performed on it. So a tweak to your pr=
oposal would be:


The only reason that example did not work is because the server deleted th=
e NP containers
after the client created them.=C2=A0 If the serve=
r does not delete the containers then
the 2nd RPC will not fail.<=
/div>

This can also be completely avoided by using the d=
efault (merge).
Since the client has to explicitly pick default-o=
peration=3Dnone,
it better know what it is doing.=C2=A0 This is t=
he same issue as a default leaf
and the create operation.=C2=A0 N=
othing special about NP containers.

The <edit-c=
onfig> for "create" will fail if the leaf already exists
=

and the "delete" will fail if the value is not there (just a=
 default).
The work-around?=C2=A0 Use merge and remove, not creat=
e and delete.
IMO the same logic applies here.


Andy




OLD:

=C2=A0 =C2=A0If=
 a container does not have a "presence" statement and the last
=C2=A0 =C2=A0child node is deleted, the NETCONF server MAY delete t=
he container.

NEW:

=

=C2=A0 =C2=A0If a container does not have a "presence" =
statement and the container instance
=C2=A0 =C2=A0does not have a=
ny child node instances, the NETCONF server MAY delete the
=C2=A0=
 =C2=A0container. It MUST create the container instance if a client <edi=
t-config> request=C2=A0
=C2=A0 =C2=A0attempts to create a chil=
d node instance within this container.


On Jul 30, 2016, at 11:52 AM, Andy=
 Bierman <andy@y=
umaworks.com> wrote:

Hi,

I strongly object to changing a vague MAY about deleting an NP conta=
iner
after the last child has been deleted into several MUST requ=
irements.

I propose this text instead:
<=
br>
OLD:


=C2=A0 =C2=
=A0If a container does not have a "presence" statement and the la=
st
=C2=A0 =C2=A0child node is deleted, the NETCONF server MAY del=
ete the container.


NEW:
<=
br>

=C2=A0 =C2=A0If a container does not have=
 a "presence" statement and the container instance
=C2=
=A0 =C2=A0does not have any child node instances, the NETCONF server MAY de=
lete the
=C2=A0 =C2=A0container. If the server does delete a cont=
ainer instance in this case, it MUST
=C2=A0 =C2=A0re-create=
 the container instance if a client <edit-config> request attempts to=
 create
=C2=A0 =C2=A0a child node instance within this container.=





Andy=



On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <<=
a href=3D"mailto:balazs.lengyel@ericsson.com" target=3D"_blank">balazs.leng=
yel@ericsson.com> wrote:

 =20
   =20
 =20
  
Hello, 

    
We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.=C2=A0 I hope=
 we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation. (Which is a slight
      violation of Netconf-6241, which we should accept.)

    
So I propose the following errata to rfc6020bis.
As for no=
n-presence containers the presence of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:
- an =
<edit-config>=C2=A0 create operation for a non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>=C2=A0 delete operation for a non-presence
      container MUST succeed even if the container does not exist.=C2=A0 
      - an <edit-config>=C2=A0 operation with default-operation=3Dnon=
e
      MUST succeed even if one or more=C2=A0 non-presence containers do not
      exist. 

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for
      organizing the hierarchy they SHOULD NOT have any must
      substatements.

    IMO the above rules remove ambiguity and follow the current
    philosophy of=C2=A0 RFC6020bis. 

    If we have a basic agreement I can formulate the text correctly.

    

    I don't know whether similar updates are needed for RestConf.

    regards Balazs

    

    PS. I still believe introducing NP containers was a mistake, however
    they are here to stay.=C2=A0 

    

    
On 2016-07-21 09:17, Jan Lindblad
      wrote:

    

    

     =20
      Xiang,
      


      

      

        

          

            

              

                
Are
                    you saying that since a NP-container is merely a
                    structure node, not config in any way, so
                    creating/deleting it explicitly (and repeatedly) is
                    equivalent to a =E2=80=9Cno-op=E2=80=9D that will alway=
s succeed
                    because doing so has no effect on the server=E2=80=99s
                    config in any way?=C2=A0

              

            

          

          


          

          
That's correct. "Creating" an object with zero=
 bits of
            information is a no-op.

          


          

          

            

              

              
If the
                  sever has the following example config:

              
<mycontainer><=
/u>

              
=C2=A0=C2=A0=C2=A0
                  =C2=A0<child =C2=A0... bla..bla=E2=80=A6configs>=


              
</mycontainer>=


              
=C2=A0
              
=C2=A0
              
If a
                  client issues an edit-config with:
              
<=C2=A0mycontaine=
r=C2=A0operation=3D"delete">
              
=C2=A0
              
The
                  server returns =E2=80=9Cok=E2=80=9D,=


              
=C2=A0
              
If then
                  again =C2=A0the client attempts:
              
=C2=A0
              
<=C2=A0mycontaine=
r=C2=A0operation=3D"delete">
              
=C2=A0
              
The
                  server should still return =C2=A0=E2=80=9Cok=E2=80=9D?

            

          

          


          

          
Yes, that's correct in my opinion. It's a consequenc=
e of
            the NP container nature as defined in the current
            RFC6020/YANG 1.0 and bis.

          
=C2=A0

          

            

              
If so I
                  think this is confusing. I think it would make more
                  sense in the latter case if the server returns =E2=80=9C<=
/span>"data-missing=E2=80=9D error.

            

          

          


          

          
This is logical if you think of NP containers as path
            prefixes, and not as objects with information content. If
            you accept that an NP container has zero bits of
            information, how would the server even know whether the
            container exists or not? Not by looking in a database, for
            sure.

          


          

          
P containers have a single bit of information, so they
            can be created, and the creation event/existence remembered
            by the server. Not so for NP-containers.

          


          

          

            

              
I
                  understand we may advise a client not do so, but since
                  =C2=A0RFC6020bis does not forbid this, and it is also a
                  perfectly valid <edit-config>, so I am sure
                  people will try it.

            

          

          


          

          
Yes. And it works today and is harmless.

          


          

          
It's unfortunate that the YANG 1.0 and 1.1 specs aren=
9;t
            crystal clear on the subject, but I believe the
            interpretation I and others have of NP container behavior in
            RFC 6020 is consistent, implementable and highly useful.

          


          

          
/jan

          


          

        

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  




_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




_______________________________________________
Netconf mailing list
=
Netconf@ietf.org<=
br>https://www.ietf.org/mailman/listinfo/netconf



Mahesh Jethanandani











--94eb2c11c304f115510538e399a4--


From nobody Sun Jul 31 16:51:41 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E1D12B043 for ; Sun, 31 Jul 2016 16:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.155
X-Spam-Level: 
X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icN9aj3vonsG for ; Sun, 31 Jul 2016 16:51:38 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A02412B03B for ; Sun, 31 Jul 2016 16:51:38 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id u25so95634171qtb.1 for ; Sun, 31 Jul 2016 16:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-transfer-encoding:subject:references:from:mime-version :in-reply-to:message-id:date:cc:to; bh=l0E5Kc32zKvbsNcOgPnvUSMWbhkhtU/DwLOhNgV0Qn4=; b=SZ8IUA6V36Gvnjc67WMzh8Wb8G050iUw7PUlSr8K52YuRrNaD5WqftgngtBbO28n3w v4xqf2LBiE4BBGxTNN6S0DKFBJfftrwtMzfyAw7VmQYwVxLRUZuDm7kZtmhv1uXES2SD sFNbDOpC8pSh4hYam7GpmNLgoKal1UKz3HxvWNF7FtcHVjj/zGlASAlYOT1wg+uT0UPm mqrKnLSpxx+Ny1euaNHkkiIwHl8QRLHJWp7nSUt2yTg9hq1aJt1fryVHERwCEfrVJUOy So1P4pWULE47cN0BI5zd1OnFfKJVcZ0zkAlHgdok6pOwnrF0g+q/SVZ6VCgzG3RsSwVU VZLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:subject:references :from:mime-version:in-reply-to:message-id:date:cc:to; bh=l0E5Kc32zKvbsNcOgPnvUSMWbhkhtU/DwLOhNgV0Qn4=; b=DlOd81o7MA6d0A84E1pkDkC2ZxUHbUm0BklxCPc8E/7kSeeyrzSoOtju6e2I1wwo2B cgBVFsbWW++WJrUlKbPrzrRG8A4h2qSHFkQ7Q0KJTOmPsPyqU9ah7hbazJ56WA0J7eGY /+qf+e3a1M5HunqA88AaIE2glypara6IPuGwHJohGAJfyH9iPm9eTi71cQKMAcDZftMI P2L5W9eKm5oehDbxtLMT6XcSiS8Zza2OwHhKrmzEWQal2hLGKdUQMPLRXIzpPqHzTpYM th6S4+bvCzrQRFRoIir1yfFDJGw5nInAihHjhQX+CT6lmJ0UJ13gcAYGbmrX9A+9Kf1C iGdQ==
X-Gm-Message-State: AEkoouv8adomnbmuxSF2bpeAehQxA/xnuOL49BGyp1btW+pMnwrLM+ysV/GE0TS7nuRF8g==
X-Received: by 10.200.34.77 with SMTP id p13mr82984254qtp.15.1470009097694; Sun, 31 Jul 2016 16:51:37 -0700 (PDT)
Received: from [172.20.5.20] ([65.202.37.3]) by smtp.gmail.com with ESMTPSA id u23sm16133169qte.30.2016.07.31.16.51.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 31 Jul 2016 16:51:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-5CD9B123-8F19-4BA0-B94F-6B9E86C2F0FF
Content-Transfer-Encoding: 7bit
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>   
From: Mahesh Jethanandani 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Message-Id: 
Date: Sun, 31 Jul 2016 10:45:49 -0700
To: Andy Bierman 
X-Mailer: iPad Mail (13F69)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jul 2016 23:51:41 -0000

--Apple-Mail-5CD9B123-8F19-4BA0-B94F-6B9E86C2F0FF
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Jul 30, 2016, at 5:31 PM, Andy Bierman  wrote:
>=20
>=20
>=20
>> On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani  wrote:
>> Andy,
>>=20
>> The thread started because the RFC does not say anything about a create o=
f a NP container. It only talked about delete. Can we make the (re-)create o=
f the NP container unconditional to whether a delete was performed on it. So=
 a tweak to your proposal would be:
>=20
> The only reason that example did not work is because the server deleted th=
e NP containers
> after the client created them.  If the server does not delete the containe=
rs then
> the 2nd RPC will not fail.

I think this argument of whether server should or should not create/delete N=
P containers is distracting from the main point of when NP containers should=
 exist. In my mind, the NP container existence depends on whether child node=
s exist or not. In the end, if child nodes exist, NP containers should exist=
 (created), if they do not exist, the NP container should be removed.

Can we agree on that?=20

P.s The errata will be much easier to craft if we can agree on this.

>=20
> This can also be completely avoided by using the default (merge).
> Since the client has to explicitly pick default-operation=3Dnone,
> it better know what it is doing.=20
> This is the same issue as a default leaf
> and the create operation.  Nothing special about NP containers.
>=20
> The  for "create" will fail if the leaf already exists
> and the "delete" will fail if the value is not there (just a default).
> The work-around?  Use merge and remove, not create and delete.
> IMO the same logic applies here.
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
>> OLD:
>>=20
>>    If a container does not have a "presence" statement and the last
>>    child node is deleted, the NETCONF server MAY delete the container.
>>=20
>> NEW:
>>=20
>>    If a container does not have a "presence" statement and the container i=
nstance
>>    does not have any child node instances, the NETCONF server MAY delete t=
he
>>    container. It MUST create the container instance if a client  request=20
>>    attempts to create a child node instance within this container.
>>=20
>>=20
>>> On Jul 30, 2016, at 11:52 AM, Andy Bierman  wrote:
>>>=20
>>> Hi,
>>>=20
>>> I strongly object to changing a vague MAY about deleting an NP container=

>>> after the last child has been deleted into several MUST requirements.
>>>=20
>>> I propose this text instead:
>>>=20
>>> OLD:
>>>=20
>>>=20
>>>    If a container does not have a "presence" statement and the last
>>>    child node is deleted, the NETCONF server MAY delete the container.
>>>=20
>>>=20
>>> NEW:
>>>=20
>>>=20
>>>    If a container does not have a "presence" statement and the container=
 instance
>>>    does not have any child node instances, the NETCONF server MAY delete=
 the
>>>    container. If the server does delete a container instance in this cas=
e, it MUST
>>>    re-create the container instance if a client  request at=
tempts to create
>>>    a child node instance within this container.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>>>> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel  wrote:
>>>> Hello,=20
>>>> We seem to have fundamental differences whether NP-containers exist/don=
't exist or if this question is even valid.  I hope we can agree that as NP-=
containers are meaningless themselves they MUST NOT influence Netconf operat=
ions or model validation. (Which is a slight violation of Netconf-6241, whic=
h we should accept.)
>>>> So I propose the following errata to rfc6020bis.
>>>>=20
>>>> As for non-presence containers the presence of the container node with n=
o child nodes is=20
>>>> semantically equivalent to the absence of the container node, configura=
tion operations or=20
>>>> model validation should never fail due to the existence or non-existenc=
e of a non-presence containers. Specifically:
>>>>=20
>>>> - an   create operation for a non-presence container MUST s=
ucceed even if the container already exists.=20
>>>> - an   delete operation for a non-presence container MUST s=
ucceed even if the container does not exist. =20
>>>> - an   operation with default-operation=3Dnone MUST succee=
d even if one or more  non-presence containers do not exist.=20
>>>> Separately
>>>> - a must statement defined as direct substatement of a non-presence con=
tainer SHALL be evaluated as part of model validation if and only if one or m=
ore child data nodes exist in the instance data or if there is a leaf or lea=
f-list child with a default value. As non-presence containers are only used f=
or organizing the hierarchy they SHOULD NOT have any must substatements.
>>>>=20
>>>> IMO the above rules remove ambiguity and follow the current philosophy o=
f  RFC6020bis.=20
>>>> If we have a basic agreement I can formulate the text correctly.
>>>>=20
>>>> I don't know whether similar updates are needed for RestConf.
>>>> regards Balazs
>>>>=20
>>>> PS. I still believe introducing NP containers was a mistake, however th=
ey are here to stay. =20
>>>>=20
>>>>> On 2016-07-21 09:17, Jan Lindblad wrote:
>>>>> Xiang,
>>>>>=20
>>>>>> Are you saying that since a NP-container is merely a structure node, n=
ot config in any way, so creating/deleting it explicitly (and repeatedly) is=
 equivalent to a =E2=80=9Cno-op=E2=80=9D that will always succeed because do=
ing so has no effect on the server=E2=80=99s config in any way?=20
>>>>>=20
>>>>> That's correct. "Creating" an object with zero bits of information is a=
 no-op.
>>>>>=20
>>>>>> If the sever has the following example config:
>>>>>> 
>>>>>>      
>>>>>> 
>>>>>> =20
>>>>>> =20
>>>>>> If a client issues an edit-config with:
>>>>>> < mycontainer operation=3D"delete">
>>>>>> =20
>>>>>> The server returns =E2=80=9Cok=E2=80=9D,
>>>>>> =20
>>>>>> If then again  the client attempts:
>>>>>> =20
>>>>>> < mycontainer operation=3D"delete">
>>>>>> =20
>>>>>> The server should still return  =E2=80=9Cok=E2=80=9D?
>>>>>=20
>>>>> Yes, that's correct in my opinion. It's a consequence of the NP contai=
ner nature as defined in the current RFC6020/YANG 1.0 and bis.
>>>>> =20
>>>>>> If so I think this is confusing. I think it would make more sense in t=
he latter case if the server returns =E2=80=9C"data-missing=E2=80=9D error.
>>>>>=20
>>>>> This is logical if you think of NP containers as path prefixes, and no=
t as objects with information content. If you accept that an NP container ha=
s zero bits of information, how would the server even know whether the conta=
iner exists or not? Not by looking in a database, for sure.
>>>>>=20
>>>>> P containers have a single bit of information, so they can be created,=
 and the creation event/existence remembered by the server. Not so for NP-co=
ntainers.
>>>>>=20
>>>>>> I understand we may advise a client not do so, but since  RFC6020bis d=
oes not forbid this, and it is also a perfectly valid , so I am=
 sure people will try it.
>>>>>=20
>>>>> Yes. And it works today and is harmless.
>>>>>=20
>>>>> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear o=
n the subject, but I believe the interpretation I and others have of NP cont=
ainer behavior in RFC 6020 is consistent, implementable and highly useful.
>>>>>=20
>>>>> /jan
>>>>=20
>>>> --=20
>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>> Senior Specialist
>>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=
=20
>>>>=20
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>=20
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>=20

--Apple-Mail-5CD9B123-8F19-4BA0-B94F-6B9E86C2F0FF
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




I think this argument of whether server shoul=
d or should not create/delete NP containers is distracting from the main poi=
nt of when NP containers should exist. In my mind, the NP container existenc=
e depends on whether child nodes exist or not. In the end, if child nodes ex=
ist, NP containers should exist (created), if they do not exist, the NP cont=
ainer should be removed.

Can we agree on that? 

P.s The errata will be much easier to craft if we can a=
gree on this.

=


Th=
is can also be completely avoided by using the default (merge).
Si=
nce the client has to explicitly pick default-operation=3Dnone,
it=
 better know what it is doing. 
This is the same issue as a default l=
eaf
and the create operation.  Nothing special about NP conta=
iners.

The <edit-config> for "create" will fa=
il if the leaf already exists
and the "delete" will fail if the va=
lue is not there (just a default).
The work-around?  Use merg=
e and remove, not create and delete.
IMO the same logic applies he=
re.


Andy



OLD:

   If a container does not have a "presence" statement and the l=
ast
   child node is deleted, the NETCONF server MAY del=
ete the container.

NEW:

<=
div>
   If a container does not have a "presence" stateme=
nt and the container instance
   does not have any child=
 node instances, the NETCONF server MAY delete the
   co=
ntainer. It MUST create the container instance if a client <edit-config&g=
t; request 
   attempts to create a child node inst=
ance within this container.


On Jul 30, 2016, at 11:52 AM, Andy Bierman <=
andy@yumaworks.com> wrote:

Hi,

I strong=
ly object to changing a vague MAY about deleting an NP container
a=
fter the last child has been deleted into several MUST requirements.

I propose this text instead:

OLD:=



   If a container do=
es not have a "presence" statement and the last
   child=
 node is deleted, the NETCONF server MAY delete the container.

NEW:


   If a container does not have a "presence" statement and the co=
ntainer instance
   does not have any child node instanc=
es, the NETCONF server MAY delete the
   container. If t=
he server does delete a container instance in this case, it MUST
=

   re-create the container instance if a client <edit-conf=
ig> request attempts to create
   a child node instan=
ce within this container.



=


Andy


=

On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <=
span dir=3D"ltr"><balazs.lengyel@ericsson.com> wrote:

 =20
   =20
 =20
  
Hello, 

    
We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.  I hope we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation. (Which is a slight
      violation of Netconf-6241, which we should accept.)

    
So I propose the following errata to rfc6020bis.
As for non=
-presence containers the presence of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:
- an &=
lt;edit-config>  create operation for a non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>  delete operation for a non-presence
      container MUST succeed even if the container does not exist.  
      - an <edit-config>  operation with default-operation=3Dnone=

      MUST succeed even if one or more  non-presence containers do not
      exist. 

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for
      organizing the hierarchy they SHOULD NOT have any must
      substatements.

    IMO the above rules remove ambiguity and follow the current
    philosophy of  RFC6020bis. 

    If we have a basic agreement I can formulate the text correctly.

    

    I don't know whether similar updates are needed for RestConf.

    regards Balazs

    

    PS. I still believe introducing NP containers was a mistake, however
    they are here to stay.  

    

    
On 2016-07-21 09:17, Jan Lindblad
      wrote:

    

    

     =20
      Xiang,
      


      

      

        

          

            

              

                
Are
                    you saying that since a NP-container is merely a
                    structure node, not config in any way, so
                    creating/deleting it explicitly (and repeatedly) is
                    equivalent to a =E2=80=9Cno-op=E2=80=9D that will always=
 succeed
                    because doing so has no effect on the server=E2=80=99s
                    config in any way? 

              

            

          

          


          

          
That's correct. "Creating" an object with zero bits of
            information is a no-op.

          


          

          

            

              

              
If the
                  sever has the following example config:

              
<mycontainer><=
/div>
              
   
                   <child  ... bla..bla=E2=80=A6configs><=
/u>

              
</mycontainer>=


              
 

              
 

              
If a
                  client issues an edit-config with:
              
< mycontainer operation=3D"d=
elete">

              
 

              
The
                  server returns =E2=80=9Cok=E2=80=9D,<=
/div>
              
 

              
If then
                  again  the client attempts:
              
 

              
< mycontainer operation=3D"d=
elete">

              
 

              
The
                  server should still return  =E2=80=9Cok=E2=80=9D?

            

          

          


          

          
Yes, that's correct in my opinion. It's a consequence of
            the NP container nature as defined in the current
            RFC6020/YANG 1.0 and bis.

          
 

          

            

              
If so I
                  think this is confusing. I think it would make more
                  sense in the latter case if the server returns =E2=80=9C"data-missing=E2=80=9D error.

            

          

          


          

          
This is logical if you think of NP containers as path
            prefixes, and not as objects with information content. If
            you accept that an NP container has zero bits of
            information, how would the server even know whether the
            container exists or not? Not by looking in a database, for
            sure.

          


          

          
P containers have a single bit of information, so they
            can be created, and the creation event/existence remembered
            by the server. Not so for NP-containers.

          


          

          

            

              
I
                  understand we may advise a client not do so, but since
                   RFC6020bis does not forbid this, and it is also a
                  perfectly valid <edit-config>, so I am sure
                  people will try it.

            

          

          


          

          
Yes. And it works today and is harmless.

          


          

          
It's unfortunate that the YANG 1.0 and 1.1 specs aren't
            crystal clear on the subject, but I believe the
            interpretation I and others have of NP container behavior in
            RFC 6020 is consistent, implementable and highly useful.

          


          

          
/jan

          


          

        

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  




_______________________________________________

Netconf mailing list

Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf




_______________________________________________
Netconf mailing list
<=
a href=3D"mailto:Netconf@ietf.org" target=3D"_blank">Netconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf



Mahesh Jethanandani









=

--Apple-Mail-5CD9B123-8F19-4BA0-B94F-6B9E86C2F0FF--


From nobody Sun Jul 31 17:20:28 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC92F12D0FC for ; Sun, 31 Jul 2016 17:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.563
X-Spam-Level: 
X-Spam-Status: No, score=0.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, TO_NO_BRKTS_PCNT=2.497] autolearn=no autolearn_force=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 xx99TByoC2qu for ; Sun, 31 Jul 2016 17:19:38 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D077B12D0D8 for ; Sun, 31 Jul 2016 17:19:37 -0700 (PDT)
Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-07v.sys.comcast.net with SMTP id U0x8b1I1Eff8qU0xFbgLpH; Mon, 01 Aug 2016 00:19:37 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id U0xDbd5H48abdU0xEbGEbB; Mon, 01 Aug 2016 00:19:36 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u710JZNc004712 for ; Sun, 31 Jul 2016 20:19:35 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u710JYeI004709; Sun, 31 Jul 2016 20:19:34 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: netconf@ietf.org
Sender: worley@ariadne.com (Dale R. Worley)
Date: Sun, 31 Jul 2016 20:19:34 -0400
Message-ID: <87y44hjq7d.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfE2LTK03GJtcBW47xQ6aNp+w6GH2Q5l01MaJ+XBYQI3V44Crs4fvHZYsHJleIGYPO98J8wSY1uXa0sIIpN4ndoj0s/9newbv2TU8Mnt0jLCWFAMLjjzD Tq0FaP+e51DJIQnaB0Yv9DMnzvKnAKoWzZtgS1tni+ArG9SE/xSHejtDdYhFdvMqEYtammRB8Ip2YQ==
Archived-At: 
Subject: [Netconf] IETF Last Call Gen-ART review of draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 00:19:56 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: review-draft-ietf-netconf-restconf-15
Reviewer: Dale R. Worley
Review Date: 29 July 2016
IETF LC End Date: 3 August 2016
IESG Telechat date: "Not yet"

Summary:

This draft is basically ready for publication, but has nits that
should be fixed before publication.

* Technical nits

- In a few places, returned data can include URIs that are intended to
be usable by the client to retrieve information from the Restconf
server.  These places include the  element for accessing an
event stream, the Location header of POST responses, and the URLs for
retrieving schema resources (section 3.7).  The problem
is that implementing this assumes that the server knows a host
identifier (domain name or address) that the client can use to access
the server.  In general, given the ubiquity of NATs, the server
doesn't know this.

It seems to me that the two possible solutions are for the server to
be able to return a URI *relative reference* or for the server to use
as the host-part of the URL the value in the Host header of the
request (which perforce the server knows the client can use to access
the server).  Perhaps this is a known problem with a known solution
and so the draft doesn't bother to mention it.  Then again, perhaps in
practice the clients and the server are in region of the network
containing no internal NATS, and the problem does not arise.

But it seems to me that this could be a very general problem for
implementers and they should be instructed how to deal with it.  I
suspect that the authors know the intended resolution of this issue,
but it would help if the resolution was stated explicitly.

- Does XRD (RFC 6415) admit relative links as values of the href
attribute of the Link element?  Relative links are not usually
considered to be "URIs", but rather "URI-references" (RFC 3986 section
4.1), and RFC 6415 uses "URI" consistently, not "URI-reference".
Also, all examples in RFC 6415 show complete URIs.  If the href
attributes have to be full URIs, then the problem with host
identifiers described above also arises.

* General issues

- Might it be useful to consistently use a trailing-backslash
convention?  There are 17 places that state "lines wrapped for display
purposes only".  And there are places where lines are wrapped without
this message, e.g., section 6.2.  It might be better for the reader to
replace all of these messages with a single statement at the top:

   When a line ends with backslash as the last (non-whitespace)
   character, it is wrapped for display purposes.  It is to be
   considered to be joined to the next line by deleting the backslash,
   the following line break, and the leading whitespace of the next
   line.

- There is a general point regarding the interpretation of data resource
URLs.  Items in leaf-lists and lists that are not configuration data
need not have unique values/keys, and so a URL that selects nodes
within a leaf-list/list by providing a value may select multiple
target nodes.  The consequences of this do not seem to be explicitly
pointed out to the reader in any place.

In regard to retrieval requests (GET or HEAD), this is handled
correctly:  If the response is to be formatted in XML, the request
fails, because XML has no method to return multiple values.  If the
response is to be formatted in JSON, the request succeeds, because
JSON can return multiple values.  (As stated in section 4.3.)

All other requests methods modify the target resource(s), and
therefore cannot be directed to non-configuration data.  But
configuration data leaf-lists/lists must have unique values/keys, so a
URL that identifies modifiable resources must identify a unique
resource.  Most of the text conforms to this fact, but in section 4.7
(regarding DELETE) is:

   If the target resource represents a YANG leaf-list or list, then the
   DELETE method SHOULD NOT delete more than one such instance.

It seems to me that this situation cannot arise.

I don't think this issue requires much change to the text.  There is
the change to section 4.7 listed above, and it seems like it would be
useful to add a general warning in section 3.5.3:

    A URI that specifies list/leaf-list values may contain a value
    that identifies multiple data nodes.  Since duplicate values are
    not permitted in configuration data, any such URI must identify
    non-configuration data.  A request with such a URI is processed
    according to the specifications of the request method; in
    particular, since non-configuration data cannot be edited, a
    request with a method that changes data will necessarily be
    rejected if the URI specifies multiple data nodes.

- The term "resource type" is used frequently but not defined.  It
seems that the set of all resources, i.e., valid URLs in the Restconf
interface, is divided into classes, each of which has a distinct
"resource type", and a distinct set of behaviors.  It would be very
useful to the reader to state this explicitly and list the resource
types.  The text almost does this implicitly, as the resource types
correspond fairly well to the subsections of section 3, though only
sections 3.1, 3.4, 3.5, 3.6, 3.7, and 3.8 correspond to resource
types.

See also the chart listing three resource types (Datastore, Data, and
Operation) in section 4.4.

There seem to be a few places where "resource media type" is used to
mean the same thing as "resource type".  It seems like it should be
replaced by "resource type".

- YANG data template

I think there is an important concept buried in the term "YANG data
template", but it isn't stated exactly anywhere, and it's not clear to
me precisely what it is.  There is an entry in section 1.1.5, "Terms":

   o  YANG data template: a schema for modeling a conceptual data
      structure in an encoding-independent manner.  It is defined with
      the "yang-data" extension, found in Section 8.  It has a
      representation with the media-type "application/yang-data" or
      "application/yang-data+json".

I can't figure out the exact relationship between "YANG data
template", "something defined with the yang-data extension", "the
schema tree of a module", and "data that implicitly has
representations using XML and JSON".

The question of what is a "YANG data template" also interacts with the
question of what the purpose of the yang-data extension is.

I'm sure that the authors at least have an intuitive understanding of
how these concepts interrelate, but it doesn't seem to me that any of
this is laid out clearly for the naive reader.

I think this can be resolved by getting clear answers to these
questions:

-- Does the word "template" have a specific meaning?

The word "template" does not appear in
draft-ietf-netmod-rfc6020bis-14.  It doesn't seem to be equivalent to
"schema tree", because that's defined as "The definition hierarchy
specified within a module.", i.e., the entire tree defined by a
module.  Template seems to be equivalent to "the subtree rooted at a
first-level schema node".

It may be that the phrase "YANG data template" would be better
replaced by some other phrase.

-- What is the significance of the phrase "a schema for modeling a
conceptual data structure in an encoding-independent manner"?

By assumption, all of the data in the implemented modules exists in an
encoding-independent manner, and the mere fact that it's accessible
via RESTCONF defines that it can be represented in XML and JSON.

-- What exactly does the yang-data extension statement do?

It seems to me that the draft doesn't need the extension.  For
example, in section 7.1 regarding error responses, the current text
is:

   When an error occurs for a request message on any resource type, and
   the status code that will be returned is in the "4xx" range (except
   for status code "403 Forbidden"), then the server SHOULD send a
   response message-body containing the information described by the
   "yang-errors" YANG template definition within the "ietf-restconf"
   module, found in Section 8.

But it seems to me that it would suffice to say 'The response
message-body contains a representation of an instance of the "errors"
container in the "ietf-restconf" module find in Section 8 (using the
module name "ietf-restconf" and the namespace
"urn:ietf:params:xml:ns:yang:ietf-restconf").'

So what is the particular value of the yang-data extension and why is
it not needed for schema trees defined in ordinary implemented
modules?

-- While we're at it, where is the specification that all Yang data
has representations in XML and JSON?

Clearly there must be such a specification, as that's necessary for
Restconf to work at all, but I've overlooked it.

- There seem to be six statements in the draft that the fragment field
in RESTCONF resource URIs has no defined purpose, either for some set
of resources or for all resources.  (sections 3.4, 3.5, 3.6, 3.8, 5.1
(twice)  But of course, the fragment identifier is never presented to
the HTTP/HTTPS server for the resource -- see RFC 7230 section 5.1:

   The target URI excludes the reference's fragment component, if any,
   since fragment identifiers are reserved for client-side processing
   ([RFC3986], Section 3.5).

It seems like a single statement of this fact would be sufficient, and
that section 5.1 is a natural place to put it, along with removing the
"fragment" field from the illustration of an HTTP request's
request-line:

         //?#

          ^       ^        ^       ^         ^
          |       |        |       |         |
        method  entry  resource  query    fragment

          M       M        O        O         I

However, the discussion of fragment identifiers in the media type
definitions is correct and proper.

- There seems to be a general inconsistency in indentation -- see the
end of the review for a list showing how each HTTP example is
indented.

- There should be only one space between the request URI and
"HTTP/1.1".  (RFC 7230 section 3.1.1)  This is done incorrectly in:

    3.1.  Root Resource Discovery
	  GET /top/restconf/operations  HTTP/1.1
    3.3.1.  {+restconf}/data
	   ?content=nonconfig  HTTP/1.1
    3.3.3.  {+restconf}/yang-library-version
       GET /restconf/yang-library-version  HTTP/1.1
    4.3.  GET
	  library/artist=Foo%20Fighters/album=Wasting%20Light  HTTP/1.1
    4.4.2.  Invoke Operation Mode
	  POST /restconf/operations/example-jukebox:play   HTTP/1.1
    4.5.  PUT
	      library/artist=Foo%20Fighters/album=Wasting%20Light   HTTP/1.1
	   library/artist=Foo%20Fighters/album=Wasting%20Light   HTTP/1.1
    D.1.1.  Retrieve the Top-level API Resource
       GET /restconf   HTTP/1.1
    D.1.3.  Retrieve The Server Capability Information
	   capabilities  HTTP/1.1
    D.2.1.  Create New Data Resources
	   library/artist=Foo%20Fighters  HTTP/1.1
    D.3.5.  "point" Parameter
	      Wasting%20Light%2Fsong%3DBridge%20Burning   HTTP/1.1

- Percent-encoding

There are some details of percent-encoding that aren't fully
specified.  Percent-encoding is described in sections 3.5.3 and 5.1,
so I've consolidated the discussion here.

One is that the Yang string character set is Unicode, so to fully
specify how percent-encoding is done, we have to specify a character
representation to map Unicode characters into octets, after which
percent-encoding can be done.  These days the expected encoding for
Unicode is UTF-8, and percent-encoding using the UTF-8 representation
is described in the final paragraph of section 2.5 of RFC 3986.  This
means that the item in section 3.5.3 should be changed from

   o  The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to [RFC3986], section 2.1.

to

   o  The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to [RFC3986], sections 2.1 and
      2.5.

and section 5.1 should be changed from

   Any reserved characters MUST be percent-encoded, according to
   [RFC3986], sections 2.1 and 2.5.

- Must "," be percent-encoded when it appears in the key value for a
leaf-list node, given that a leaf-list path component cannot have more
than one key values?  See the comments for section 3.5.3.

- There are a number of questions regarding the ABNF in section
3.5.3.1 and precisely which URLs must conform to that syntax.  See the
comments for that section.

- Is the ietf-restconf module listed in
{+restconf}/data/ietf-restconf-monitoring:modules-state/module?  I can
see that this could be argued either way.  See the comments for
section 10.1.1.

- Generally, a colon in JSON is formatted with one space before and
one space after.  But these lines are formatted differently:

            "@mtu": {
        "ietf-restconf:errors": {
              "error-type": "protocol",
              "error-tag": "lock-denied",
              "error-message": "Lock failed, lock already held"
        "ietf-restconf:restconf": {
        "ietf-yang-library:modules-state": {
          "module-set-id": "5479120c17a619545ea6aff7aa19838b036ebbd7",
          "ietf-yang-library:modules-state": {

* Nits

Table of Contents

   ...
   8.  RESTCONF module . . . . . . . . . . . . . . . . . . . . . . .  66

This should be "RESTCONF Module".

1.  Introduction

   If a RESTCONF server is co-located with a NETCONF server, then there
   are protocol interactions to be considered, as described in
   Section 1.4.

This is a bit vague, as it doesn't specify with *what* protocols there
are interactions.  But this is obvious to most readers, as it's
concerned with interaction with the Netconf protocol.  But it's not
obvious to readers who don't know Netconf, because the preceding text
only describes Netconf as a system of datastore semantics.  So I think
this could be clarified by modifying this sentence:

   NETCONF defines configuration datastores and a set of Create,
   Retrieve, Update, Delete (CRUD) operations that can be used to access
   these datastores.

to

   NETCONF defines configuration datastores; a set of Create,
   Retrieve, Update, Delete (CRUD) operations that can be used to access
   these datastores; and a protocol for invoking those operations.

and modifying the above sentence to

   If a RESTCONF server is co-located with a NETCONF server, then there
   are protocol interactions with the NETCONF protocol, which are described in
   Section 1.4.

and changing the first sentence/paragraph of 1.4 to

   RESTCONF can be implemented on a device that supports the NETCONF protocol.

--

   Data-model specific RPC operations defined with the YANG "rpc" or [...]

I think this should start "Data-model-specific", as all of that phrase
is an adjective that modifies "RPC".  Similarly in the following
sentence, and other places in the draft.

1.1.5.  Terms

The term "operation" is used in at least three senses:

- HTTP request methods (e.g., the title of section 4)
- abstract CRUD operations
- RPC operations, viz., from the Yang "rpc" and "action" statements.

and also within

- edit operation: a RESTCONF operation on a data resource using
  either a POST, PUT, PATCH, or DELETE method.

You need to check that you have ways to specify each of these, and
that all uses of "operation" are unambiguous.  It might be useful to
mention this ambiguity in the lexicon item for "operations".

   o  API resource: a resource that models the RESTCONF entry point and
      the sub-resources to access YANG-defined content.  It is defined
      with the YANG data template named "yang-api" in the
      "ietf-restconf" module.

This should probably start "the resource that ...", as there is only one.

   o  data resource: a resource that models a YANG data node.  It is
      defined with YANG data definition statements, and YANG containers,
      leafs, leaf-list entries, list entries, anydata and anyxml nodes
      can be data resources.

It seems redundant to say "and YANG containers, leafs, leaf-list
entries, list entries, anydata and anyxml nodes can be data
resources.", because that is the whole list of YANG entities that can
be data nodes.  Worse, if a new YANG data node type is added, this
list will have to be updated.  Would it be acceptable to delete the
second sentence?

   o  datastore resource: a resource that models a programmatic
      interface to NETCONF datastores.

This should probably start "the resource that ...", as there is only one.

I think "NETCONF datastores" should be "the NETCONF datastore", since a
datastore resource must model exactly one NETCONF datastore.

   o  event stream resource: This resource represents an SSE (Server-
      Sent Events) event stream.  The content consists of text using the
      media type "text/event-stream", as defined by the SSE
      [W3C.REC-eventsource-20150203] specification.  Each event
      represents one  message generated by the server.  It
      contains a conceptual system or data-model specific event that is
      delivered within an event notification stream.  Also called a
      "stream resource".

What is a " message"?  Is  a concept from the
NETCONF protocol?  It is not used elsewhere in the draft.

Also, an event does not represent a notification message, a
notification message represents an event.

The "It" in "It contains a conceptual system" seems ambiguous.  Do you
mean "Each message contains ..."?

Also, it seems that "system or data-model specific event" would be
clearer as "system event or data-model-specific event", to make it
clear that "system" is an adjective.

   o  patch: a generic PATCH request on the target datastore or data
      resource.  The media type of the message-body content will
      identify the patch type in use.

Does the "generic" add meaning here, or can it be omitted without
loss?

   o  plain patch: a specific PATCH request type, defined in
      Section 4.6.1, that can be used for simple merge operations.  It
      has a representation with the media-type "application/yang-data"
      or "application/yang-data+json".

I don't think that "PATCH request type" is defined.  Also the use of
"representation" is odd.  Perhaps:

   o  plain patch: a specific PATCH request type, defined in
      Section 4.6.1, that can be used for simple merge operations.  It
      is specified by a request Content-Type of "application/yang-data"
      or "application/yang-data+json".

--

   o  RESTCONF capability: An optional RESTCONF protocol feature
      supported by the server, which is identified by an IANA registered
      NETCONF Capability URI, and advertised with an entry in the
      "capability" leaf-list in Section 9.3.

Probably should be "[...] leaf-list defined in Section 9.3.".

   o  RESTCONF client: a client which implements the RESTCONF protocol.
      Also called "client".

It seems to me that the "Also called ..." clauses (for "client",
"server", and "stream resource") should be turned into stand-alone
entries, as otherwise it's difficult to find the definition of
"client", etc.

   o  schema resource: a resource that has a representation with the
      media type "application/yang".  The schema resource is used by the
      client to retrieve the YANG schema with the GET method.

Is the defining characteristic of a schema resource that it 'has a
representation with the media type "application/yang"'?  Or is its
defining characteristic the fact that "the client [can use it] to
retrieve the YANG schema"?  If the latter, I suggest reversing the
two sentences:

   o  schema resource: a resource that can be used by the client to
      retrieve a YANG schema.  It has a representation with the
      media type "application/yang".

--

1.2.  Subset of NETCONF Functionality

   The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data
   resources represented by YANG data models.  These basic edit
   operations allow the running configuration to be altered in an all-
   or-none fashion.

What is the meaning of "all-or-none" here?  Initially, I though it
meant that the actions were atomic, in that they either succeeded
completely or had no effect, but it might be referring to the fact
that RESTCONF cannot assemble a transaction from several elementary
editing operations.

   RESTCONF is not intended to replace NETCONF, but rather provide an
   additional interface that follows Representational State Transfer
   (REST) principles [rest-dissertation], and is compatible with a
   resource-oriented device abstraction.

Given the first sentence of section 1, the major goal of RESTCONF
seems to be to be HTTP-based, so it might be more accurate to say
"... to provide an HTTP interface that follows ...".

Could "compatible with a resource-oriented device abstraction" be more
usefully expressed as "compatible with the NETCONF datastore model"?

      +-----------+           +-----------------+
      |  Web app  | <-------> |                 |
      +-----------+   HTTP    | network device  |
                              |                 |
      +-----------+           |   +-----------+ |
      |  NMS app  | <-------> |   | datastore | |
      +-----------+  NETCONF  |   +-----------+ |
                              +-----------------+

The figure does not show that the "Web app" is using RESTCONF -- it's
an illustration of the use of RESTCONF that doesn't specify where
RESTCONF is used!  Perhaps change to "RESTCONF over HTTP"?

"NMS" is used nowhere else in the draft.  I assume it means "network
management system".  Perhaps all readers are expected to know that.
Otherwise, "NETCONF client" would be better.  (And can't a network
management system use Restconf?)

1.3.  Data Model Driven API

   Using YANG, a client can predict all management resources, much like
   using URI Templates [RFC6570], but in a more holistic manner.

Better,

   Knowing the YANG modules describing the server's data model, a
   client can derive all management resource URLs and the proper
   structure of all RESTCONF requests and responses.

--

   RESTCONF provides the YANG module capability information supported by
   the server, in case the client wants to use it.  The URIs for data-
   model specific RPC operations and datastore content are predictable,
   based on the YANG module definitions.

I've folded the second sentence of this passage into the previous
edit.  It seems like the first sentence could be phrased more simply,
"RESTCONF allows the client to retrieve the list of YANG modules
supported by the server."  Actually, I'm not sure that's correct; what
is "the YANG module capability information"?  The only use of
"capability" in draft-ietf-netmod-rfc6020bis-14 is for the capability
identifier URI urn:ietf:params:netconf:capability:yang-library:1.0,
which is mandatory to implement (since there is no other version
defined).

You might want to note here that the server might provide the
definitions of the modules that it supports.  E.g., "The server can
optionally support retrieval of the YANG modules it supports; see
Section 3.7."

   The RESTCONF datastore editing model is simple and direct, similar to
   the behavior of the :writable-running capability in NETCONF.  Each
   RESTCONF edit of a datastore resource is activated upon successful
   completion of the transaction.

I don't know the exact terminology that is used in this field, but I
think the final word would better be "edit".  The problem is that
"transaction" is used in the database world to mean everything
starting with the first edit operation and ending with the commit to
permanent storage.  With that definition, the "completion of the
transaction" happens only after the commit is finished.  But in this
context, the commit is the same as "a datastore resource is
activated"!

1.4.  Coexistence with NETCONF

It seems to me that the section would more accurately be described as
"Datastore and transaction management".

   If the device supports :startup, the device MUST automatically update
   the non-volatile "startup datastore", after the running datastore has
   been updated as a consequence of a RESTCONF edit operation.

Is there a reason that there are double-quotes around "startup
datastore"?  I do not see that usage in RFC 6241.

1.5.  RESTCONF Extensibility

   This document defines version 1 of the RESTCONF protocol.  If a
   future version of this protocol is defined, then that document will
   specify how the new version of RESTCONF is identified.  It is
   expected that a different entry point {+restconf2} would be defined.

The symbol "{+restconf2}" has no defined meaning.  I think you want
"It is expected that a different entry point will be used, which will
be located using a different link relation (Section 3.1)."

      Response
      --------
      HTTP/1.1 200 OK
      Content-Type: application/xrd+xml
      Content-Length: nnn

   
       
       
   

The response message-body isn't indented to the same margin as the
headers.

   Typically this extension mechanism is used to identify optional query
   parameters but it is not limited to that purpose.

Should this say "optional query parameters that are supported"?  Also,
could "Typically" be improved as "Currently"?

2.2.  HTTPS with X.509v3 Certificates

   The use the X.509v3 based certificates is consistent with NETCONF
   over TLS [RFC7589].

There is a syntax error in the first few words of this sentence.

   The RESTCONF client MUST either use X.509 certificate path validation
   [RFC5280] to verify the integrity of the RESTCONF server's TLS
   certificate, or match the presented X.509 certificate with locally
   configured certificate fingerprints.

   The presented X.509 certificate MUST also be considered valid if it
   matches a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a locally configured certificate fingerprint, the
   connection MUST be terminated as defined in [RFC5246].

The second sentence seems to be redundant with the second clause of
the first sentence.  (Or is it intended that the client MUST be
configurable with fingerprints?)  The last sentence seems to be
verbose; it should be possible to say "If the certificate cannot be
validated by either method, ...".

3.  Resources

   A resource has a representation associated with a media type
   identifier, as represented by the "Content-Type" header in the HTTP
   response message.

This seems awkward.  Perhaps:

   A resource has one or more representations, each associated with a
   different media type.  When a representation of a resource is sent
   in an HTTP response message, the associated media type is given in
   the "Content-Type" header.

--

   All RESTCONF resource types are defined in this document except
   specific datastore contents, RPC operations, and event notifications.

This depends on exactly what "resource type" means.  As discussed at
the beginning, that phrase seems to mean a small, finite number of
resource classes that are all defined in this document.  I think what
this sentence is trying to get at is that the specific resources of a
particular server that are in each of the resource type classes is
determined by the set of modules the server implements.  But that
isn't what the sentence says (assuming I'm correct about what
"resource type" means).

   The syntax and semantics for these resource types are defined in YANG
   modules.

Perhaps "... are defined in the YANG modules that the server
implements.".

   The RESTCONF protocol does not include a data resource discovery
   mechanism.  Instead, the definitions within the YANG modules
   advertised by the server are used to construct a predictable
   operation or data resource identifier.

It seems like "predictable" is redundant given the use of "construct".

3.1.  Root Resource Discovery

   After discovering the RESTCONF API root, the client MUST prepend it
   to any subsequent request to a RESTCONF resource.

It's not actually prepended to the *request*, it's the initial part of
the path of the request URI:

   The RESTCONF API root is used as the initial part of the path of
   the request URI of any request to a RESTCONF resource.

Because of the resource discovery system, any given host:port can
support only one RESTCONF server.  This means that a particular host
is not expected to support an arbitrarily large number of RESTCONF
servers, as each server must use a different port.  I doubt this is a
practical limitation for the intended usages, but it's probably worth
mentioning in the Introduction.

3.3.  API Resource

   +--rw restconf
      +--rw data
      +--rw operations
      +--ro yang-library-version

That seems to imply that the root resource has the name "restconf" (or
perhaps that the last component of its name is "restconf").  I think
you could be more accurate (with some abuse of notation) by:

   +--rw {+restconf}
      +--rw data
      +--rw operations
      +--ro yang-library-version

Section 1.7 says 'Ellipsis ("...") stands for contents of subtrees
that are not shown.', but ellipsis is not exploited here to clarify
where in the tree additional nodes will be:

   +--rw {+restconf}
      +--rw data
      |  ...
      +--rw operations?
      |  ...
      +--ro yang-library-version

Section 3.3.2 states that "operations" is optional, so there should be
a "?" after "operations".

   The "yang-api" YANG data template is defined with the "yang-data"
   extension in the "ietf-restconf" module, found in Section 8.  It is
   used to specify the structure and syntax of the conceptual child
   resources within the API resource.

I think this would be clearer if you said '... defined using the
"yang-data" extension', and "It specifies the structure and syntax
...".

3.4.  Datastore Resource

   The "{+restconf}/data" subtree represents the datastore resource
   type, which is a collection of configuration data and state data
   nodes.

Shouldn't this be "... represents the datastore, which is ..."?

   This resource type is an abstraction of the system's underlying
   datastore implementation.  It is used to simplify resource editing
   for the client.  The RESTCONF datastore resource is a conceptual
   collection of all configuration and state data that is present on the
   device.

The first sentence is extremely clear.  The second sentence is odd;
doesn't it mean "The client uses it to edit resources."?  The third
sentence seems to be a longer statement of the first sentence, given
what the datastore is.

   Configuration edit transaction management and configuration
   persistence are handled by the server and not controlled by the
   client.  A datastore resource can be written directly with the POST
   and PATCH methods.  Each RESTCONF edit of a datastore resource is
   saved to non-volatile storage by the server, if the server supports
   non-volatile storage of configuration data.

The second sentence makes sense in this context.  The first and third
sentences are datastore management, which is discussed in section 1.4.

3.4.1.  Edit Collision Detection

   Two "edit collision detection" mechanisms are provided in RESTCONF,
   for datastore and data resources.

Why are there double-quotes around "edit collision detection"?

There seems to be a third mechanism:  if the datastore is locked, the
request gets a 409 response (section 1.4).  Though maybe that's more
"collision prevention" than "collision detection".

3.4.1.1.  Timestamp

   If the RESTCONF server is colocated with a NETCONF server, then the
   last-modified timestamp MUST represent the "running" datastore.

"represent" isn't the right word here.  Perhaps "... MUST be that of
...".  Of course, this fact is implicit in the Restconf definition,
because Restconf provides access only to the running datastore, but
it's worth warning the implementer explicitly.

3.4.1.2.  Entity tag

   A unique opaque string is maintained and the "ETag" ([RFC7232],
   Section 2.3) header is returned in the response for a retrieval
   request.  The "If-Match" header can be used in edit operation
   requests to cause the server to reject the request if the resource
   entity tag does not match the specified value.

It seems you want 2119 language here:

   The server MUST maintain a unique opaque entity-tag for the
   datastore resource and MUST return it in the "ETag" ([RFC7232],
   Section 2.3) header in the response for a retrieval request.  The
   client MAY use an "If-Match" header in edit operation requests to
   cause the server to reject the request if the resource entity tag
   does not match the specified value.

An interesting point that you may want to warn the reader about is
that the entity-tag encodes not only the data in the resource but also
its representation; different representations (XML vs. JSON) must have
different entity-tags.  (RFC 7323 section 2.3)

   If the RESTCONF server is colocated with a NETCONF server, then this
   entity tag MUST represent the "running" datastore.

"represent" isn't the right word here.  Perhaps "... MUST be that of ...".

3.4.1.3.  Update Procedure

It seems like the substantial part of this section is "Changes to
configuration data resources affect the timestamp and entity tag to
... the datastore resource."  The rest of what it says is more fully
described in section 3.5.  It seems that the real point is to state
that changing any of the configuration resources changes the
timestamp/ETag of the datastore resource, which is more or less
understood, given that the datastore has a timestamp/ETag.  But it
seems that this could be more clearly said in 3.4.1:

   Two "edit collision detection" mechanisms are provided in RESTCONF
   for the datastore:  a timestamp and an ETag.  (These may also be
   provided for data resources; see Section 3.5.)  Any change to
   configuration data resources updates the timestamp and entity tag
   of the datastore resource.

3.5.  Data Resource

   A configuration data resource can be altered by the client with some
   or all of the edit operations, depending on the target resource and
   the specific operation.  Refer to Section 4 for more details on edit
   operations.

It seems like this paragraph is largely redundant.

3.5.3.  Encoding Data Resource Identifiers in the Request URI

   In YANG, data nodes are identified with an absolute XPath expression,
   defined in [XPath], starting from the document root to the target
   resource.  In RESTCONF, URI-encoded path expressions are used
   instead.

I think "are identified" should be "can be identified" -- relative
XPath is also allowed in Yang.

   If a node in the
   path is defined in another module than its parent node, then module
   name followed by a colon character (":") is prepended to the node
   name in the resource identifier.

That should start "If a node in the path is defined in another module
than its parent node, or its parent is the datastore, then module
...".

The following item appears in the list concerning list nodes:

   o  The key value is specified as a string, using the canonical
      representation for the YANG data type.  Any reserved characters
      MUST be percent-encoded, according to [RFC3986], section 2.1.

This fact also needs to be specified for leaf-list nodes, so either
this item should be duplicated into the list of items for leaf-list
nodes, or it should be pulled out as a top-level paragraph.

The reader needs to be warned that in the the character "," in a key
value must also be percent-encoded, despite that it is not considered
"reserved" in any definition of URL.

This leads to a technical nit:  Must "," be percent-encoded when it
appears in the key value for a leaf-list node, given that a leaf-list
path component cannot have more than one key values?  (Whether this is
specified as true or false is not important, but the standard needs to
fix the requirement.)

   Resource URI values returned in Location headers for data resources
   MUST identify the module name as specified in
   [I-D.ietf-netmod-yang-json], even if there are no conflicting local
   names when the resource is created.  This ensures the correct
   resource will be identified even if the server loads a new module
   that the old client does not know about.

It's not clear that this restriction adds anything.  Module names are
required in resource URIs already, by "If a node in the path is
defined in another module than its parent node, [or its parent is the
datastore,] then module name followed by a colon character (":") is
prepended to the node name in the resource identifier."

3.5.3.1.  ABNF For Data Resource Identifiers

       api-path = "/"  |
                  ("/" api-identifier
                    0*("/" (api-identifier | list-instance )))

I'm assuming there that  is the syntax for the path *within*
the API's section of the URL space, that is, the string which is
appended to the entry point {+restconf}.  This seems necessary, as
otherwise the segments of the entry point path would have to conform
to , and that restriction seems pointless.  But this
point should probably be clarified in the text.

It seems that this ABNF only applies to the paths of data resource
identifiers, not other resource types.  But in that case, why does the
syntax allow "/" alone, which isn't the path of a data resource?
Indeed, a data resource path must start with "/data/" and be followed
by at least one segment.  ({+restconf}/data is the path of the
datastore resource, which is a different resource type.)

       key-value = string      ;; note 1

Of course, this is omitting the constraints about percent-encoding
reserved characters and comma.

   Note 1: The syntax for "api-identifier" and "key-value" MUST conform
   to the JSON identifier encoding rules in Section 4 of
   [I-D.ietf-netmod-yang-json].

Is this note actually correct?

3.6.  Operation Resource

   For example, if "module-A" defined a "reset" rpc operation, then
   invoking the operation from "module-A" would be requested as follows:

It seems like 'from "module-A"' is redundant in this context; we've
already stated that the operation is in module-A.

   All operation resources representing RPC operations supported by the
   server MUST be identified in the {+restconf}/operations subtree
   defined in Section 3.3.2.  Operation resources representing YANG
   actions are not identified in this subtree since they are invoked
   using a URI within the {+restconf}/data subtree.

Isn't this paragraph redundant given the discussion at the beginning
of the section?

3.6.2.  Encoding Operation Resource Output Parameters

   The request URI is not returned in the response.  This URI might have
   context information required to associate the output to the specific
   "rpc" or "action" statement used in the request.

Doesn't HTTP always allow the client to associate the response with
the request that generated it?  If so, this paragraph is not really
correct, as a returned request URI will not be "required" for the
client to perform the association.  Perhaps what is meant is
"knowledge of the request URI is needed to associate the output to the
specific "rpc" or "action" statement referenced in the request".

3.8.  Event Stream Resource

   The available streams can be retrieved from the stream list, which
   specifies the syntax and semantics of a stream resource.

Shouldn't that be "... the syntax and semantics of the stream resources"?

3.9.  Errors YANG Data Template

   An "errors" YANG data template models a collection of error
   information [...]

Presumably, 'The "errors" YANG data template ...'.

4.  Operations

   The following table shows how the RESTCONF operations relate to
   NETCONF protocol operations and edit operations, which are identified
   with the NETCONF "nc:operation" attribute.

For people who don't know NETCONF, it would be clearer to say
'... NETCONF protocol operations, and for the NETCONF edit operations,
the "nc:operation" attribute.'

   In particular, RESTCONF is compatible with the NETCONF
   Access Control Model (NACM) [RFC6536], as there is a specific mapping
   between RESTCONF and NETCONF operations, defined in Section 4.

Since this text is contains in Section 4, you could omit "defined in
Section 4".

   Implementation of all methods (except PATCH) are defined in
   [RFC7231].  This section defines the RESTCONF protocol usage for each
   HTTP method.

Why no RFC reference for the definition of PATCH?

4.2.  HEAD

   The HEAD method is sent by the client to retrieve just the headers
   that would be returned for the comparable GET method, without the
   response message-body.  It is supported for all resource types,
   except operation resources.

It seems a lot safer (and future-proof) to say "It is supported by all
resources that support GET."

Also, it might be helpful to expand the first sentence, "... just the
headers (which contain the metadata for a resource) ...".

4.3.  GET

   The request MUST contain a request URI that contains at least the
   entry point.

Uses of the term "entry point" are scattered through the document but
not listed in 1.1.5.

I assume that it is implicit how a JSON GET should return multiple
values.  It might help the reader to include an example of a GET that
returns multiple nodes (using JSON, of course).

BTW, what ETag and timestamp is returned by a GET whose URI identifies
more than one value?

4.5.  PUT

   If the target resource represents a YANG list instance, then the PUT
   method MUST NOT change any key leaf values in the message-body
   representation.

Shouldn't this be "... any key leaf values in the instance."?

4.6.1.  Plain Patch

   Please see
   [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting
   the ability to delete child resources.  The YANG Patch Media Type
   allows multiple sub-operations (e.g., merge, delete) within a single
   PATCH operation.

It seems these two sentences would be clearer if they were combined:

   Please see [I-D.ietf-netconf-yang-patch] for an alternate
   media-type that supports the deleting child resources and
   specifying multiple sub-operations (e.g., merge, delete) within a
   single PATCH operation.

--

   If the target resource represents a YANG list instance, then the
   PATCH method MUST NOT change any key leaf values in the message-body
   representation.

Shouldn't that be "... any key leaf values in the instance"?

Section 4.6.1 needs to specify that the plain patch operation never
returns a response message-body.

4.7.  DELETE

   To delete a resource such as the "album" resource, the client might
   send:

This would be clearer if it was

   To delete the "album" resource with the key "Wasting Light", the client
   might send:

4.8.2.  The "depth" Query Parameter

   The "depth" parameter is used to specify the number of nest levels
   returned in a response for a GET method.

This would be better as 'Data nodes with a depth value exceeding the
"depth" parameter are not returned in a response for a GET method.'

   The first nest-level consists of the requested data node itself.

It seems that this would be more clear as "The requested data node
itself has depth value of 1."

   If the "fields" parameter (Section 4.8.3) is used to select
   descendant data nodes, these nodes all have a depth value of 1.

You want to augment this as:

   If the "fields" parameter (Section 4.8.3) is used to select
   descendant data nodes, these nodes and all their ancestors have a
   depth value of 1.

The following text could be clarified by adding parentheses around
this sentence:

   (This has the effect of including the nodes specified by the
   fields, even if the "depth" value is less than the actual depth
   level of the specified fields.)

--

   Any child nodes which are contained within a parent node have a
   depth value that is 1 greater than its parent.

Probably better as "Any other child node has a depth value that is ...".

   By default, the server will include all sub-resources within a
   retrieved resource, which have the same resource type as the
   requested resource.  The exception is the datastore resource.  If
   this resource type is retrieved then by default the datastore and all
   child data resources are returned.

This specification requires that "resource type" be well-defined.

4.8.3.  The "fields" Query Parameter

There should be a note that using "fields" does not select out a set
of nodes whose values are returned as a *set* of values, it returns a
*single* value, which is the value of the target data node, pruned by
the removal of all nodes that are not ancestors of or descendants of
one of the nodes specified in the "fields" parameter.  This is
particularly important when considering the interaction of "fields"
and "depth", and also is significant when the response representation
is XML.

4.8.4.  The "filter" Query Parameter

   This parameter is only allowed for GET methods on a text/event-stream
   data resource.

This is probably better put as "... on an event stream resource".

Similarly in section 4.8.7.

4.8.7.  The "start-time" Query Parameter

   If this query parameter is supported by the server, then the "replay"
   query parameter URI MUST be listed in the "capability" leaf-list in
   Section 9.3.  The "stop-time" query parameter MUST also be supported
   by the server.

For correctness, I think you need to join the two sentences:
'... leaf-list in Section 9.3, and the "stop-time" query parameter
MUST ...'.

Similarly in section 4.8.8.

4.8.9.  The "with-defaults" Query Parameter

   If the "with-defaults" parameter is set to "report-all-tagged" then
   the server MUST adhere to the defaults reporting behavior defined in
   Section 3.4 of [RFC6243].

This needs a note that section 5.3 provides additional information
about how default values are marked in responses when "with-defaults"
is "report-all-tagged".

5.2.  Message Encoding

   JSON encoding rules are defined in
   [I-D.ietf-netmod-yang-json].  JSON encoding of metadata is defined in
   [I-D.ietf-netmod-yang-metadata].

There needs to be some sort of juncture between these two sentences.
Does I-D.ietf-netmod-yang-json apply to metadata as well?  If so, the
second sentence should start "Additional JSON encoding rules for
metadata are ...".  If not, the subject of the first sentence should
be modified to show that metadata is excluded.  ("JSON encoding rules
for data are ..."?)

   Response output content
   encoding format is identified with the Accept header in the request.

This should be

   The response output content encoding formats that the client will
   accept are identified with the Accept header in the request.

--

   File extensions encoded
   in the request are not used to identify format encoding.

I don't know of any place where a file extension can be encoded in the
request.  But I get the unpleasant feeling that some server in the
wild has been seen with this behavior and this warning is needed!

5.3.  RESTCONF Metadata

   With the XML encoding, the metadata is encoded as attributes in XML.

There should be some reference here as to how it should be done.
Presumably this is a reference to RFC 6243.

5.3.2.  JSON MetaData Encoding Example

   [...] so the YANG module name has to be assigned instead of derived
   from the YANG module name.

I don't think this is can be correct; one use of "YANG module name" is
probably intended to be something else.

"MetaData" should be "Metadata".

6.3.1.  NETCONF Event Stream

   The server SHOULD support the "NETCONF" notification stream defined
   in [RFC5277].

It might help to note that the reference is to section 3.2.3 of RFC
5277.

Is "notification stream" the same as "event stream"?  It seems like
the draft should use one term or the other consistently.

There is a lot of information about query parameters here, but it
seems that it duplicates the discussion of query parameters elsewhere
in the draft.  Could it be abbreviated?

6.4.  Receiving Event Notifications

   The structure of the event data is based on the "notification"
   element definition in Section 4 of [RFC5277].  It MUST conform to the
   schema for the "notification" element in Section 4 of [RFC5277],
   except the XML namespace for this element is defined as:

   urn:ietf:params:xml:ns:yang:ietf-restconf

"this element" is somewhat ambiguous; probably better as "the event
data element".

   RESTCONF servers that do send the
   "id" field MUST still support the "startTime" query parameter as the
   preferred means for a client to specify where to restart the event
   stream.

It seems "startTime" should be "start-time".

But what is the significance of "MUST" here?  Implementing
"start-time" is always optional (section 6.3.1).  Perhaps it would
work to say

    RESTCONF servers that send the "id" field SHOULD support the
    "start-time" query parameter, as "start-time" is the preferred
    means for specifying where to restart fetching the event stream.

7.  Error Reporting

   The  element returned in NETCONF error
   responses contains some useful information.

I got confused by this sentence.  IIRC, this section is about error
responses generally, not just error responses for RPC operations.  It
seems the problem is that *all* Netconf operations are considered
RPCs, so  covers all Netconf errors.  I think this could be
made less confusing by combining this sentence with the following one
as:

   The error information that NETCONF error responses contain in the
    element is adapted for use in RESTCONF, and an 
   data tree information is returned for "4xx" and "5xx" class of
   status codes.

--

   [...] a mapping between the NETCONF  value and the HTTP status
   code is needed.

Better to say "a mapping from the ... to the HTTP status code is
needed." since the reverse mapping is not unique.

   The semantics and syntax for RESTCONF error messages are defined with
   the "yang-errors" YANG data template extension, found in Section 8.

What is a "YANG data template extension"?  It probably means "YANG
data template extension statement", but I think it could be reduced to
'the "errors" YANG data template'.  (Of course, see my comments about
"YANG data template" at the beginning.)

7.1.  Error Response Message

   The Content-Type of this response
   message MUST be a subtype of application/yang-data (see example
   below).

This isn't the meaning of "subtype", which seems to be restricted (RFC
6838) to mean the part of the media type after "/".  This should work,
though:

   The Content-Type of this response message MUST be
   application/yang-data, plus optionally a structured syntax name
   suffix.

"structured syntax name suffix" is defined in RFC 6838 section 4.2.8.

   The client SHOULD specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media is specified, [...]

The client will specify the desired encoding for all responses, which
perforce applies to error messages as well.  This can probably be
reduced to:

   The client SHOULD specify the desired encoding(s) for response
   messages by specifying the appropriate media-type(s) in the Accept
   header.  If the client did not specify an Accept header, [...]

--

   No response message-body content is expected by the
   client in this example.

Well, no content is expected on success, but the client was prepared
for failure by providing an Accept.  Better say

   There would be no response message-body content if this operation
   was successful.

The indentation of the DELETE example request and its response are
different, which should probably be fixed.

8.  RESTCONF module

        Note that the YANG definitions within this module do not
        represent configuration data of any kind.

Are there kinds of configuration data?  Seems like it would be better
to say "... are never configuration data."

And indeed, we could add 'config "false";' to the top-level objects to
specify that directly in Yang.

     ...

     extension yang-data {
      argument name {

Is there a reason that the substatements of this extension statement
are indented only 1 space?

        yin-element true;
      }
      description
        "This extension is used to specify a YANG data template which
         represents conceptual data defined in YANG. It is
         intended to describe hierarchical data independent of
         protocol context or specific message encoding format.
         Data definition statements within this extension specify
         the generic syntax for the specific YANG data template.

"this extension" is ambiguous, since it seems to me that it might be
referring to the immediately preceding extension-statement.  I think
the last sentence would be clearer as

         Data definition statements within a yang-data extension
         statement specify the generic syntax for the specific YANG
         data template, whose name is the argument of the yang-data
         extension statement.

--

         This extension is ignored unless it appears as a top-level
         statement. It SHOULD contain data definition statements
         that result in exactly one container data node definition.

It seems like you can assure that the extension will never be used in
an improper place, since only this document will use it.  Perhaps

         The yang-data extension MUST only be a top-level statement of
         a module.  It MUST contain only one schema node, which is a
         container.

--

         This allows compliant translation to an XML instance
         document for each YANG data template.

This needs to specify the source of the name of the top-level XML
element:

	 Instances of a YANG data template can thus be translated into
	 XML instances, whose top-level element corresponds to the
	 top-level container.

--

         The following data-def-stmt sub-statements have special
         meaning when used within a yang-data-resource extension
         statement.
         - The list-stmt is not required to have a key-stmt defined.
         - The if-feature-stmt is ignored if present.
         - The config-stmt is ignored if present.
         - The available identity values for any 'identityref'
           leaf or leaf-list nodes is limited to the module
           containing this extension statement, and the modules
           imported into that module.

It seems like poor practice to have the extension be described as
changing the semantics of Yang.  Better would be to turn these into
constraints, so that the valid contents of yang-data are a subset of
Yang, but that subset has the same semantics as Yang prescribes:

         - The if-feature-stmt must not be present.
         - If the config-stmt is present, its value must be 'false'.
         - The available identity values for any 'identityref'
           leaf or leaf-list nodes is limited to the module
           containing this extension statement, and the modules
           imported into that module. [unchanged!]

The item "The list-stmt is not required to have a key-stmt defined."
is redundant, since everything inside yang-data is not configuration
data, and non-configuration lists need not have keys.

This section contains the following lines which name media types which
do not exist.  Presumably this is a simple oversight and the correct
types are known.

          application/yang-api resource type.";

            application/yang-api resource type.";

             "Container representing the application/yang-datastore

              (application/yang-operation),

9.  RESTCONF Monitoring

   The "ietf-restconf-monitoring" module provides information about the
   RESTCONF protocol capabilities and event notification streams
   available from the server.  A RESTCONF server MUST implement the "/
   restconf-state/capabilities" container in this module.

Note that there is a line break in an incorrect place at the end of
the third line.  Presumably it is due to an extraneous space in the
XML2RFC file.

It seems like the second sentence would be more informative as "A
RESTCONF server MUST implement the ietf-restconf-monitoring module."
Since restconf-state/capabilities is mandatory within the module, its
existence need not be stated here.

   YANG Tree Diagram for "ietf-restconf-monitoring" module:

Shouldn't that be "YANG tree diagram ..."?

The nodes 'description' and 'replay-support' are shown as optional in
the tree diagram:

   +--ro restconf-state
      +--ro streams
         +--ro stream* [name]
            +--ro description?                string
            +--ro replay-support?             boolean
            +--ro replay-log-creation-time?   yang:date-and-time

but there is no 'mandatory "false";' for those leafs in the module
definition in section 9.3:

           leaf description {
             type string;
             description "Description of stream content";
             reference
               "RFC 5277, Section 3.4,  element.";
           }

           leaf replay-support {
             type boolean;
             description
               "Indicates if replay buffer supported for this stream.
                If 'true', then the server MUST support the 'start-time'
                and 'stop-time' query parameters for this stream.";
             reference
               "RFC 5277, Section 3.4,  element.";
           }

And the description should say that if replay-support is missing, its
assumed value is false[?].  Or should a 'default' statement be
employed?

9.1.2.  The "defaults" Protocol Capability URI

This section is awkwardly phrased.  Perhaps:

   This URI identifies the "basic-mode" defaults handling mode that is
   used by the server for processing default leafs in requests for
   data resources.  This protocol capability URI MUST be supported by
   the server, and MUST be listed in the "capability" leaf-list in
   Section 9.3.

      +----------+--------------------------------------------------+
      | Name     | URI                                              |
      +----------+--------------------------------------------------+
      | defaults | urn:ietf:params:restconf:capability:defaults:1.0 |
      +----------+--------------------------------------------------+

                     RESTCONF defaults capability URI

   This URI MUST have attached a query a parameter named "basic-mode"
   with one of the values listed below:

   +------------------+------------------------------------------------+
   | Value            | Description                                    |
   +------------------+------------------------------------------------+
   | report-all       | No data nodes are considered default           |
   | trim             | Values set to the YANG default-stmt value are  |
   |                  | default                                        |
   | explicit         | Values set by the client are never considered  |
   |                  | default                                        |
   +------------------+------------------------------------------------+

   The "basic-mode" behavior of the server is as specified for this
   value in "With-Defaults Capability for NETCONF" [RFC6243]:

   If the "basic-mode" is set to "report-all" then the server MUST
   adhere to the defaults handling behavior defined in Section 2.1 of
   [RFC6243].
   [...]

9.2.  restconf-state/streams

   This optional container provides access to the event notification
   streams supported by the server.  The server MAY omit this container
   if no event notification streams are supported.

The second sentence is redundant, given that "streams" is a
non-presence container, but it seems reasonable to warn the
implementer here.

10.1.  modules-state

   This mandatory container holds the identifiers for the YANG data
   model modules supported by the server.

This isn't how I'd phrase it.  I would say that modules-state/module
holds the identifiers.  Perhaps omit this section and number 10.1.1 as
"10.1"?

10.1.1.  modules-state/module

If I understand correctly, the resource tree under {+restconf} is
described by the ietf-restconf module.  All data resources not defined
by ietf-restconf are descendants of {+restconf}/data, including the
mandatory ietf-restconf-monitoring module.  But is ietf-restconf
listed in
{+restconf}/data/ietf-restconf-monitoring:modules-state/module?  I can
see that this could be argued either way.

12.  Security Considerations

   The "ietf-restconf-monitoring" YANG module defined in this memo is
   designed to be accessed via the NETCONF protocol [RFC6241].  The
   lowest NETCONF layer is the secure transport layer, and the
   mandatory-to-implement secure transport is Secure Shell (SSH)
   [RFC6242].  The NETCONF access control model [RFC6536] provides the
   means to restrict access for particular NETCONF users to a pre-
   configured subset of all available NETCONF protocol operations and
   content.

This reads oddly.  "ietf-restconf-monitoring" is designed to be
accessed via the RESTCONF protocol.  However, RESTCONF does use the
NETCONF access control model.  OTOH, this paragraph really isn't about
ietf-restconf-monitoring, it's very general.  It seems to me that you
want (and I may have the details wrong):

   The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement
   secure transport is TLS [RFC5246].  The RESTCONF protocol uses the
   NETCONF access control model [RFC6536], which provides the means to
   restrict access for particular RESTCONF users to a preconfigured
   subset of all available RESTCONF protocol operations and content.

   This section provides security considerations for the resources
   defined by the RESTCONF protocol.  Security considerations for
   HTTPS are defined in [RFC7230].  RESTCONF does not specify which
   YANG modules a server needs to support, other than the
   "ietf-restconf-monitoring" module.  Security considerations for the
   other modules manipulated by RESTCONF can be found in the documents
   defining those YANG modules.

14.1.  Normative References

This draft has the longest normative references list I've ever seen!

14.2.  Informative References

   [rest-dissertation]
              Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000.

Surely there is additional bibliographic information available for
this!

Appendix C.  Example YANG Module

   +---x play
      +--ro input
         +--ro playlist       string
         +--ro song-number    uint32

The "x" indicator is not listed in section 1.1.7.  Is it "standard"
for Yang tree diagrams?

The "+---x" before "play" should be "+--x".  This will also fix the
indenting problem.

C.1.  example-jukebox YANG Module

      ...
      contact "support at example.com";

Comparing with the examples of the contact statement in
draft-ietf-netmod-rfc6020bis-14, it seems that this should be
"support@example.com".

Appendix D.  RESTCONF Message Examples

   The examples within this document use the normative YANG module
   defined in Section 8 and the non-normative example YANG module
   defined in Appendix C.1.

This would flow better (for me) if it included the module names:

   The examples within this document use the normative YANG module
   "ietf-restconf" defined in Section 8 and the non-normative example
   YANG module "example-jukebox" defined in Appendix C.1.

D.1.1.  Retrieve the Top-level API Resource

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang-data+json

      {
        "ietf-restconf:restconf": {
          "data" : {},
          "operations" : {},
          "yang-library-version" : "2016-04-09"
        }
      }

   The server will return the same response either way, which might be
   as follows :

It's not really the "same response".  "conceptual data" seems better.

D.2.2.  Detect Resource Entity Tag Change

   In this example, the server just supports the datastore last-changed
   timestamp.  The client has previously retrieved the "Last-Modified"
   header and has some value cached to provide in the following request
   to patch an "album" list entry with key value "Wasting Light".  Only
   the "genre" field is being updated.

IIRC, the "value cached" is the URI
/restconf/data/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light
for the album.  It seems this could be clearer as

   After the previous request, the client has cached the
   "Last-Modified" header and the Location header from the response to
   provide the following request to patch the "album" list entry with
   key value "Wasting Light".

And then change the If-Unmodified-Since header in the request to use
the value from the previous response, "Mon, 23 Apr 2012 17:03:00 GMT".

D.2.3.  Edit a Datastore Resource

   In this example, the client modifies two different data nodes by
   sending a PATCH to the datastore resource:

"different" might be redundant.

It might be worth pointing out which nodes are being modified.  As far
as I can see, the only modifiable nodes in the request data tree are
the "year" nodes, but the "year" for "Wasting Light" in this update is
the same as in its creation in D.2.1.  Should the request be modified?

D.2.4.  Edit a Data Resource

   In this example, the client modifies one data nodes by sending a
   PATCH to the data resource (URI wrapped for display purposes only):

   PATCH /restconf/data/example-jukebox:jukebox/library/
      artist=Nick%20Cave%20and%20the%Bad%20Seeds HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data

   
     Nick Cave and the Bad Seeds
     
       The Good Son
       1990
     
   

Should be "one data node".

The example isn't very clear to me:  Which data node(s) is the PATCH
intended to modify?  Does "modify a data node" mean that one single
leaf is being modified, or does it include modification of an entire
subtree?  "the data resource" seems to be an "artist" node, but that
node per se isn't being modified.

I think it would help to write what changes the PATCH was intended to
cause, and adjust the wording accordingly.

D.3.2.  "depth" Parameter

   To determine if 1 or more resource instances exist for a given target
   resource, the value "1" is used.

Usually, this "1" would be spelled out as "one".

The following two sections probably should have short text identifying
what they illustrate.  E.g.,

D.3.7.  "start-time" Parameter

   The following URI shows an example of a start-time specification:

   // start-time = 2014-10-25T10:02:00Z
   GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z

D.3.8.  "stop-time" Parameter

   The following URI shows an example of a stop-time specification:

   // stop-time = 2014-10-25T12:31:00Z
   GET /mystreams/NETCONF?stop-time=2014-10-25T12%3A31%3A00Z

This example is invalid, since it doesn't contain a start-time.
(section 4.8.8) Perhaps:

   The following URI shows an example of a stop-time specification
   (lines wrapped for display purposes only):

   // start-time = 2014-10-25T10:02:00Z
   // stop-time = 2014-10-25T12:31:00Z
   GET /streams/NETCONF?
      start-time=2014-10-25T10%3A02%3A00Z&
      stop-time=2014-10-25T12%3A31%3A00Z

D.3.9.  "with-defaults" Parameter

   The following YANG module is assumed for this example.

     module example-interface {
       prefix "exif";
       namespace "urn:example.com:params:xml:ns:yang:example-interface";

       container interfaces {
         list interface {
           key name;
           leaf name { type string; }
           leaf mtu { type uint32; }
           leaf status {
             config false;
             type enumeration {
               enum up;
               enum down;
               enum testing;
             }
           }
         }
       }
     }

As far as I can tell, module "example-interface" isn't used in this
section.  "example-interface" seems to be an abbreviated version of
module "example" in section A.1 of RFC 6243, but with the semantic
difference that "example-interface" omits the default statement that
drives the examples in this section.  It seems that you want to drop
"example-interface" entirely and start the section with:

   Assume the server implements the module "example" defined in
   Appendix A.1 of [RFC6243].  Assume the server's datastore is as
   defined in Appendix A.2 of [RFC6243].

----------------------------------------------------------------------
Indentation of HTTP examples

1.5.  RESTCONF Extensibility
      GET /.well-known/host-meta HTTP/1.1
      HTTP/1.1 200 OK
3.1.  Root Resource Discovery
      GET /.well-known/host-meta HTTP/1.1
      HTTP/1.1 200 OK
      GET /.well-known/host-meta HTTP/1.1
      HTTP/1.1 200 OK
      GET /top/restconf/operations  HTTP/1.1
      HTTP/1.1 200 OK
3.3.1.  {+restconf}/data
   GET /restconf/data/example-jukebox:jukebox/library
   HTTP/1.1 200 OK
3.3.3.  {+restconf}/yang-library-version
   GET /restconf/yang-library-version  HTTP/1.1
   HTTP/1.1 200 OK
3.6.  Operation Resource
   POST /restconf/operations/module-A:reset HTTP/1.1
   POST /restconf/data/module-A:interfaces/reset-all HTTP/1.1
3.6.1.  Encoding Operation Resource Input Parameters
   POST /restconf/operations/example-ops:reboot HTTP/1.1
   HTTP/1.1 204 No Content
      POST /restconf/operations/example-ops:reboot HTTP/1.1
   POST /restconf/data/example-actions:interfaces/interface=eth0
   HTTP/1.1 204 No Content
      POST /restconf/data/example-actions:interfaces/interface=eth0
3.6.2.  Encoding Operation Resource Output Parameters
   POST /restconf/operations/example-ops:get-reboot-info HTTP/1.1
      HTTP/1.1 200 OK
   HTTP/1.1 200 OK
   POST /restconf/data/example-actions:interfaces/interface=eth0
      HTTP/1.1 200 OK
3.6.3.  Encoding Operation Resource Errors
   POST /restconf/operations/example-ops:reboot HTTP/1.1
   HTTP/1.1 400 Bad Request
      HTTP/1.1 400 Bad Request
3.7.  Schema Resource
   GET /restconf/data/ietf-yang-library:modules-state/module=
      HTTP/1.1 200 OK
      HTTP/1.1
      HTTP/1.1 200 OK
4.3.  GET
   GET /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 200 OK
4.4.1.  Create Resource Mode
      POST /restconf/data HTTP/1.1
   HTTP/1.1 201 Created
4.4.2.  Invoke Operation Mode
      POST /restconf/operations/example-jukebox:play   HTTP/1.1
   HTTP/1.1 204 No Content
4.5.  PUT
      PUT /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 204 No Content
   PUT /restconf/data/example-jukebox:jukebox/
4.6.1.  Plain Patch
   PATCH /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 204 No Content
4.7.  DELETE
   DELETE /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 204 No Content
5.3.1.  XML MetaData Encoding Example
   GET /restconf/data/interfaces/interface=eth1
   HTTP/1.1 200 OK
5.3.2.  JSON MetaData Encoding Example
   GET /restconf/data/interfaces/interface=eth1
      HTTP/1.1 200 OK
6.2.  Event Streams
   GET /restconf/data/ietf-restconf-monitoring:restconf-state/
   HTTP/1.1 200 OK
6.3.  Subscribing to Receive Notifications
   GET /restconf/data/ietf-restconf-monitoring:restconf-state/
   HTTP/1.1 200 OK
   GET /streams/NETCONF HTTP/1.1
   GET /streams/NETCONF HTTP/1.1
7.1.  Error Response Message
   DELETE /restconf/data/example-jukebox:jukebox/
      HTTP/1.1 409 Conflict
   POST /restconf/data/example-jukebox:jukebox HTTP/1.1
   HTTP/1.1 409 Conflict
8.  RESTCONF module
                 POST /restconf/operations/ietf-system:system-restart
                 GET /restconf/operations
D.1.1.  Retrieve the Top-level API Resource
   GET /.well-known/host-meta HTTP/1.1
   HTTP/1.1 200 OK
   GET /restconf   HTTP/1.1
      HTTP/1.1 200 OK
   GET /restconf HTTP/1.1
   HTTP/1.1 200 OK
D.1.2.  Retrieve The Server Module Information
   GET /restconf/data/ietf-yang-library:modules-state HTTP/1.1
      HTTP/1.1 200 OK
D.1.3.  Retrieve The Server Capability Information
   GET /restconf/data/ietf-restconf-monitoring:restconf-state/
   HTTP/1.1 200 OK
D.2.1.  Create New Data Resources
      POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1
   HTTP/1.1 201 Created
   POST /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 201 Created
D.2.2.  Detect Resource Entity Tag Change
      PATCH /restconf/data/example-jukebox:jukebox/
          HTTP/1.1
   HTTP/1.1 412 Precondition Failed
D.2.3.  Edit a Datastore Resource
   PATCH /restconf/data HTTP/1.1
D.2.4.  Edit a Data Resource
   PATCH /restconf/data/example-jukebox:jukebox/library/
D.3.1.  "content" Parameter
   GET /restconf/data/example-events:events?content=all
       HTTP/1.1
      HTTP/1.1 200 OK
   GET /restconf/data/example-events:events?content=config
       HTTP/1.1
      HTTP/1.1 200 OK
   GET /restconf/data/example-events:events?content=nonconfig
       HTTP/1.1
      HTTP/1.1 200 OK
D.3.2.  "depth" Parameter
   GET /restconf/data/example-jukebox:jukebox?depth=unbounded
       HTTP/1.1
      HTTP/1.1 200 OK
   GET /restconf/data/example-jukebox:jukebox?depth=1 HTTP/1.1
      HTTP/1.1 200 OK
   GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
      HTTP/1.1 200 OK
D.3.3.  "fields" Parameter
   GET /restconf/data?fields=ietf-yang-library:modules-state/
      HTTP/1.1 200 OK
D.3.4.  "insert" Parameter
      POST /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 201 Created
D.3.5.  "point" Parameter
      POST /restconf/data/example-jukebox:jukebox/
   HTTP/1.1 204 No Content
D.3.6.  "filter" Parameter
      GET /streams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault'
      GET /streams/NETCONF?filter=%2Fevent%2Fseverity%3C%3D4
      GET /streams/SNMP?filter=%2FlinkUp%7C%2FlinkDown
      GET /streams/NETCONF?
      GET /streams/critical-syslog?
      GET /streams/NETCONF?
      GET /streams/NETCONF?filter=(%2Fm1%3A*%20or%20%2Fm2%3A*)
D.3.7.  "start-time" Parameter
   GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z
D.3.8.  "stop-time" Parameter
   GET /mystreams/NETCONF?stop-time=2014-10-25T12%3A31%3A00Z
D.3.9.  "with-defaults" Parameter
   GET /restconf/data/example:interfaces/interface=eth1 HTTP/1.1
      HTTP/1.1 200 OK
   GET /restconf/data/example:interfaces/interface=eth1
      HTTP/1.1 200 OK
----------------------------------------------------------------------

Dale


From nobody Sun Jul 31 17:23:16 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B6212B056 for ; Sun, 31 Jul 2016 17:23:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnzoCwmpL4tJ for ; Sun, 31 Jul 2016 17:23:12 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308C312B01F for ; Sun, 31 Jul 2016 17:23:12 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id w127so88868775vkh.2 for ; Sun, 31 Jul 2016 17:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eCFW48urmYFaHqUjpPCdKmOD59SimTZ1cgnPoFkGdKk=; b=q52H7QGykewLxtiPkvO/i+OiKoSC+HXkg4+c0I59uMeaz02CfrCE7S063EnwIyw4rX FhW64/+FoxWZ86FOXTQUziDxM5iLr7ckkKg7I8bXugup0atZ6LWamrbqDp52TEp/0No1 duhQAv9Kd6gWuq08jrNJ5TENhFfhXxyRu8fEWBCY/PJ0VcY7WN/B6tVwswbmqxDRrtOC WctCFPPLSrPElf0HKq0nsI8eQ+OXMrD3gPFAKT0h2lXBSLgdHalZm0+rresVwxHVqYxQ KvHhpPZusZMij8s+XM53SM+zgb1UcAasgc2Q2gcNFKWPlKzv12Zt1uBTizkm00sR5nS6 e4Mw==
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; bh=eCFW48urmYFaHqUjpPCdKmOD59SimTZ1cgnPoFkGdKk=; b=jFdlrdPZL8dHJrUxFB+3LiJO+5hoU/VfJFeaDgjeZoFCDTopaS7z44CaIWcGvglIB9 eW/TdcBRSp86KF7ahbbudtyq+DfGKNZCdic9xyU8gSNPBo7Gj8HIrY7E6E86dN2ftODG YyLzPHgjZ/6OY9yJqXQviX0D6yUN9hDkgqjguYQFf3ARQw+QkPeCYMovDHNMZsKcAoIG MSJaArrFsEcA4nK8oWawnJgwvNRAoaLxNjRquJOXoAQUkbIb1F0vE8/YdzMrrU3UjYJ8 tBddDomhAiQ/m10krCeHqBkkubAWeQqgkrkMvjmzcWf8wLcCNsODM0H/NfNiVzFEtLT5 vB+A==
X-Gm-Message-State: AEkoouvF3ksg5/dnHAX7qyFhPwcxoncmpCDYkwGFfI47NdLB7F8V6LkK3fFyPA4N3ZFLdDCl0N3Tvi4uWGixkg==
X-Received: by 10.31.9.67 with SMTP id 64mr24280898vkj.89.1470010991216; Sun, 31 Jul 2016 17:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Sun, 31 Jul 2016 17:23:10 -0700 (PDT)
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>      <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>    
From: Andy Bierman 
Date: Sun, 31 Jul 2016 17:23:10 -0700
Message-ID: 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=001a11440ef4f2b0ed0538f79a40
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 00:23:15 -0000

--001a11440ef4f2b0ed0538f79a40
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

>
> On Jul 30, 2016, at 5:31 PM, Andy Bierman  wrote:
>
>
>
> On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
>
>> Andy,
>>
>> The thread started because the RFC does not say anything about a create
>> of a NP container. It only talked about delete. Can we make the (re-)cre=
ate
>> of the NP container unconditional to whether a delete was performed on i=
t.
>> So a tweak to your proposal would be:
>>
>>
> The only reason that example did not work is because the server deleted
> the NP containers
> after the client created them.  If the server does not delete the
> containers then
> the 2nd RPC will not fail.
>
>
> I think this argument of whether server should or should not create/delet=
e
> NP containers is distracting from the main point of when NP containers
> should exist. In my mind, the NP container existence depends on whether
> child nodes exist or not. In the end, if child nodes exist, NP containers
> should exist (created), if they do not exist, the NP container should be
> removed.
>
> Can we agree on that?
>


No.

"should be removed" is an implementation choice.
It started as MAY be removed.  It needs to stay that way.

As I have pointed out 100 times,  the protocol has merge and replace
for the situation where the client is not exactly aware of how ceration and
deletion will be handled on the server.

There is no reason to force implementations to change.
If you magically delete containers, then magically recreate them.
If you don't then the nodes will be as the client expects, so no problem.


Andy


>
> P.s The errata will be much easier to craft if we can agree on this.
>
>
> This can also be completely avoided by using the default (merge).
> Since the client has to explicitly pick default-operation=3Dnone,
> it better know what it is doing.
>
> This is the same issue as a default leaf
> and the create operation.  Nothing special about NP containers.
>
> The  for "create" will fail if the leaf already exists
> and the "delete" will fail if the value is not there (just a default).
> The work-around?  Use merge and remove, not create and delete.
> IMO the same logic applies here.
>
>
> Andy
>
>
>
>
> OLD:
>>
>>    If a container does not have a "presence" statement and the last
>>    child node is deleted, the NETCONF server MAY delete the container.
>>
>> NEW:
>>
>>    If a container does not have a "presence" statement and the container
>> instance
>>    does not have any child node instances, the NETCONF server MAY delete
>> the
>>    container. It MUST create the container instance if a client
>>  request
>>    attempts to create a child node instance within this container.
>>
>>
>> On Jul 30, 2016, at 11:52 AM, Andy Bierman  wrote:
>>
>> Hi,
>>
>> I strongly object to changing a vague MAY about deleting an NP container
>> after the last child has been deleted into several MUST requirements.
>>
>> I propose this text instead:
>>
>> OLD:
>>
>>
>>    If a container does not have a "presence" statement and the last
>>    child node is deleted, the NETCONF server MAY delete the container.
>>
>>
>> NEW:
>>
>>
>>    If a container does not have a "presence" statement and the container
>> instance
>>    does not have any child node instances, the NETCONF server MAY delete
>> the
>>    container. If the server does delete a container instance in this
>> case, it MUST
>>    re-create the container instance if a client  request
>> attempts to create
>>    a child node instance within this container.
>>
>>
>>
>>
>> Andy
>>
>>
>> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <
>> balazs.lengyel@ericsson.com> wrote:
>>
>>> Hello,
>>>
>>> We seem to have fundamental differences whether NP-containers
>>> exist/don't exist or if this question is even valid.  I hope we can agr=
ee
>>> that as NP-containers are meaningless themselves they MUST NOT influenc=
e
>>> Netconf operations or model validation. (Which is a slight violation of
>>> Netconf-6241, which we should accept.)
>>>
>>> So I propose the following errata to rfc6020bis.
>>>
>>> As for non-presence containers the presence of the container node with
>>> no child nodes is
>>> semantically equivalent to the absence of the container node,
>>> configuration operations or
>>> model validation should never fail due to the existence or non-existenc=
e
>>> of a non-presence containers. Specifically:
>>>
>>> - an   create operation for a non-presence container MUST
>>> succeed even if the container already exists.
>>> - an   delete operation for a non-presence container MUST
>>> succeed even if the container does not exist.
>>> - an   operation with default-operation=3Dnone MUST succee=
d
>>> even if one or more  non-presence containers do not exist.
>>>
>>> Separately
>>> - a must statement defined as direct substatement of a non-presence
>>> container SHALL be evaluated as part of model validation if and only if=
 one
>>> or more child data nodes exist in the instance data or if there is a le=
af
>>> or leaf-list child with a default value. As non-presence containers are
>>> only used for organizing the hierarchy they SHOULD NOT have any must
>>> substatements.
>>> IMO the above rules remove ambiguity and follow the current philosophy
>>> of  RFC6020bis.
>>> If we have a basic agreement I can formulate the text correctly.
>>>
>>> I don't know whether similar updates are needed for RestConf.
>>> regards Balazs
>>>
>>> PS. I still believe introducing NP containers was a mistake, however
>>> they are here to stay.
>>>
>>> On 2016-07-21 09:17, Jan Lindblad wrote:
>>>
>>> Xiang,
>>>
>>> Are you saying that since a NP-container is merely a structure node, no=
t
>>> config in any way, so creating/deleting it explicitly (and repeatedly) =
is
>>> equivalent to a =E2=80=9Cno-op=E2=80=9D that will always succeed becaus=
e doing so has no
>>> effect on the server=E2=80=99s config in any way?
>>>
>>>
>>> That's correct. "Creating" an object with zero bits of information is a
>>> no-op.
>>>
>>> If the sever has the following example config:
>>> 
>>>      
>>> 
>>>
>>>
>>> If a client issues an edit-config with:
>>> < mycontainer operation=3D"delete">
>>>
>>> The server returns =E2=80=9Cok=E2=80=9D,
>>>
>>> If then again  the client attempts:
>>>
>>> < mycontainer operation=3D"delete">
>>>
>>> The server should still return  =E2=80=9Cok=E2=80=9D?
>>>
>>>
>>> Yes, that's correct in my opinion. It's a consequence of the NP
>>> container nature as defined in the current RFC6020/YANG 1.0 and bis.
>>>
>>>
>>> If so I think this is confusing. I think it would make more sense in th=
e
>>> latter case if the server returns =E2=80=9C"data-missing=E2=80=9D error=
.
>>>
>>>
>>> This is logical if you think of NP containers as path prefixes, and not
>>> as objects with information content. If you accept that an NP container=
 has
>>> zero bits of information, how would the server even know whether the
>>> container exists or not? Not by looking in a database, for sure.
>>>
>>> P containers have a single bit of information, so they can be created,
>>> and the creation event/existence remembered by the server. Not so for
>>> NP-containers.
>>>
>>> I understand we may advise a client not do so, but since  RFC6020bis
>>> does not forbid this, and it is also a perfectly valid , s=
o I
>>> am sure people will try it.
>>>
>>>
>>> Yes. And it works today and is harmless.
>>>
>>> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear o=
n
>>> the subject, but I believe the interpretation I and others have of NP
>>> container behavior in RFC 6020 is consistent, implementable and highly
>>> useful.
>>>
>>> /jan
>>>
>>>
>>> --
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>> Senior Specialist
>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>>
>>
>>
>>
>>
>

--001a11440ef4f2b0ed0538f79a40
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani <mjethanan=
dani@gmail.com> wrote:

On Jul 30, 2016, at 5:31 PM, Andy Bierman=
 <andy@yumaworks=
.com> wrote:



On Sat,=
 Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <mjethanandani@gmail.c=
om> wrote:
Andy,

The thread started because the=
 RFC does not say anything about a create of a NP container. It only talked=
 about delete. Can we make the (re-)create of the NP container unconditiona=
l to whether a delete was performed on it. So a tweak to your proposal woul=
d be:


The only r=
eason that example did not work is because the server deleted the NP contai=
ners
after the client created them.=C2=A0 If the server does not =
delete the containers then
the 2nd RPC will not fail.
=


I think this argument of whet=
her server should or should not create/delete NP containers is distracting =
from the main point of when NP containers should exist. In my mind, the NP =
container existence depends on whether child nodes exist or not. In the end=
, if child nodes exist, NP containers should exist (created), if they do no=
t exist, the NP container should be removed.

Can we agre=
e on that?=C2=A0


No.

"should be removed" is an implement=
ation choice.
It started as MAY be removed.=C2=A0 It needs to sta=
y that way.

As I have pointed out 100 times, =C2=
=A0the protocol has merge and replace
for the situation where the=
 client is not exactly aware of how ceration and
deletion will be=
 handled on the server.

There is no reason to forc=
e implementations to change.
If you magically delete containers, =
then magically recreate them.
If you don't then the nodes wil=
l be as the client expects, so no problem.


Andy
=C2=A0

P.s The errata will be much easier to craf=
t if we can agree on this.

This can also be completely avoided by using the default (merg=
e).
Since the client has to explicitly pick default-operation=3Dn=
one,
it better know what it is doing.=C2=A0
<=
div class=3D"gmail_extra">
This is the same =
issue as a default leaf
and the create operation.=C2=A0 Nothing s=
pecial about NP containers.

The <edit-config>=
; for "create" will fail if the leaf already exists
and=
 the "delete" will fail if the value is not there (just a default=
).
The work-around?=C2=A0 Use merge and remove, not create and de=
lete.
IMO the same logic applies here.

<=
br>
Andy



<=
br>
OLD:

=C2=A0 =C2=A0If a conta=
iner does not have a "presence" statement and the last
=
=C2=A0 =C2=A0child node is deleted, the NETCONF server MAY delete the conta=
iner.

NEW:

=C2=A0 =C2=A0If a container does not have a "presence" statemen=
t and the container instance
=C2=A0 =C2=A0does not have any child=
 node instances, the NETCONF server MAY delete the
=C2=A0 =C2=A0c=
ontainer. It MUST create the container instance if a client <edit-config=
> request=C2=A0
=C2=A0 =C2=A0attempts to create a child node i=
nstance within this container.


On Jul 30, 2016, at 11:52 AM, Andy Bierman=
 <andy@yumaworks=
.com> wrote:

Hi,

I=
 strongly object to changing a vague MAY about deleting an NP container
after the last child has been deleted into several MUST requirements=
.

I propose this text instead:

OLD:


=C2=A0 =C2=A0If a c=
ontainer does not have a "presence" statement and the last
<=
div>=C2=A0 =C2=A0child node is deleted, the NETCONF server MAY delete the c=
ontainer.


NEW:

=


=C2=A0 =C2=A0If a container does not have a "=
presence" statement and the container instance
=C2=A0 =C2=A0=
does not have any child node instances, the NETCONF server MAY delete the
=C2=A0 =C2=A0container. If the server does delete a container inst=
ance in this case, it MUST
=C2=A0 =C2=A0re-create the conta=
iner instance if a client <edit-config> request attempts to create
=C2=A0 =C2=A0a child node instance within this container.




Andy


On Fri=
, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <balazs.lengyel@ericss=
on.com> wrote:

 =20
   =20
 =20
  
Hello, 

    
We seem to have fundamental differences whether NP-containers
      exist/don't exist or if this question is even valid.=C2=A0 I hope=
 we
      can agree that as NP-containers are meaningless themselves they
      MUST NOT influence
      Netconf operations or model validation. (Which is a slight
      violation of Netconf-6241, which we should accept.)

    
So I propose the following errata to rfc6020bis.
As for no=
n-presence containers the presence of the container node
      with no child nodes is 

      semantically equivalent to the absence of the container node,
      configuration operations or 

      model validation should never fail due to the existence or
      non-existence of a non-presence containers. Specifically:
- an =
<edit-config>=C2=A0 create operation for a non-presence
      container MUST succeed even if the container already exists. 

      - an <edit-config>=C2=A0 delete operation for a non-presence
      container MUST succeed even if the container does not exist.=C2=A0 
      - an <edit-config>=C2=A0 operation with default-operation=3Dnon=
e
      MUST succeed even if one or more=C2=A0 non-presence containers do not
      exist. 

    
Separately

      - a must statement defined as direct substatement of a
      non-presence container SHALL be evaluated as part of model
      validation if and only if one or more child data nodes exist in
      the instance data or if there is a leaf or leaf-list child with a
      default value. As non-presence containers are only used for
      organizing the hierarchy they SHOULD NOT have any must
      substatements.

    IMO the above rules remove ambiguity and follow the current
    philosophy of=C2=A0 RFC6020bis. 

    If we have a basic agreement I can formulate the text correctly.

    

    I don't know whether similar updates are needed for RestConf.

    regards Balazs

    

    PS. I still believe introducing NP containers was a mistake, however
    they are here to stay.=C2=A0 

    

    
On 2016-07-21 09:17, Jan Lindblad
      wrote:

    

    

     =20
      Xiang,
      


      

      

        

          

            

              

                
Are
                    you saying that since a NP-container is merely a
                    structure node, not config in any way, so
                    creating/deleting it explicitly (and repeatedly) is
                    equivalent to a =E2=80=9Cno-op=E2=80=9D that will alway=
s succeed
                    because doing so has no effect on the server=E2=80=99s
                    config in any way?=C2=A0

              

            

          

          


          

          
That's correct. "Creating" an object with zero=
 bits of
            information is a no-op.

          


          

          

            

              

              
If the
                  sever has the following example config:

              
<mycontainer><=
/u>

              
=C2=A0=C2=A0=C2=A0
                  =C2=A0<child =C2=A0... bla..bla=E2=80=A6configs>=


              
</mycontainer>=


              
=C2=A0
              
=C2=A0
              
If a
                  client issues an edit-config with:
              
<=C2=A0mycontaine=
r=C2=A0operation=3D"delete">
              
=C2=A0
              
The
                  server returns =E2=80=9Cok=E2=80=9D,=


              
=C2=A0
              
If then
                  again =C2=A0the client attempts:
              
=C2=A0
              
<=C2=A0mycontaine=
r=C2=A0operation=3D"delete">
              
=C2=A0
              
The
                  server should still return =C2=A0=E2=80=9Cok=E2=80=9D?

            

          

          


          

          
Yes, that's correct in my opinion. It's a consequenc=
e of
            the NP container nature as defined in the current
            RFC6020/YANG 1.0 and bis.

          
=C2=A0

          

            

              
If so I
                  think this is confusing. I think it would make more
                  sense in the latter case if the server returns =E2=80=9C<=
/span>"data-missing=E2=80=9D error.

            

          

          


          

          
This is logical if you think of NP containers as path
            prefixes, and not as objects with information content. If
            you accept that an NP container has zero bits of
            information, how would the server even know whether the
            container exists or not? Not by looking in a database, for
            sure.

          


          

          
P containers have a single bit of information, so they
            can be created, and the creation event/existence remembered
            by the server. Not so for NP-containers.

          


          

          

            

              
I
                  understand we may advise a client not do so, but since
                  =C2=A0RFC6020bis does not forbid this, and it is also a
                  perfectly valid <edit-config>, so I am sure
                  people will try it.

            

          

          


          

          
Yes. And it works today and is harmless.

          


          

          
It's unfortunate that the YANG 1.0 and 1.1 specs aren=
9;t
            crystal clear on the subject, but I believe the
            interpretation I and others have of NP container behavior in
            RFC 6020 is consistent, implementable and highly useful.

          


          

          
/jan

          


          

        

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  




_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




_______________________________________________
Netconf mailing list
=
Netconf@ietf.org<=
br>https://www.ietf.org/mailman/listinfo/netconf



Mahesh Jethanandani














--001a11440ef4f2b0ed0538f79a40--


From nobody Sun Jul 31 18:13:24 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F5612B057 for ; Sun, 31 Jul 2016 18:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 J-AHKQh9VMaA for ; Sun, 31 Jul 2016 18:13:22 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721D512D0C4 for ; Sun, 31 Jul 2016 18:13:22 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with SMTP id U1kxb0BG284vjU1nFbYskf; Mon, 01 Aug 2016 01:13:21 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id U1nEbsrMUS9gdU1nFb9ois; Mon, 01 Aug 2016 01:13:21 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u711DJXa010081; Sun, 31 Jul 2016 21:13:19 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u711DJ3Q010078; Sun, 31 Jul 2016 21:13:19 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Mahesh Jethanandani 
In-Reply-To:  (mjethanandani@gmail.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Sun, 31 Jul 2016 21:13:19 -0400
Message-ID: <87vazljnps.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfHeag74j/QnHBGHRHQyCP2YI3plGhkyRu4nblAQFvckNemPKPNY0o89tZbNplLaygDebspL0KNflO/vff3WAoNrFiMsgLhIsLuyzEoYXgazkJcYQZQv7 ZCsv2ZOomRiXFxte26vn1uOf8liGCIoS1vjuYbWCHZQcjGylWHzocYTpUJtmBngX1jSnhfYp39pdK6X+xjB9/IWYf4oBR89e5/K+qzbJqNNtfwAtPH+czoNc 26f0cikMY8s/Vt7iJ5b1Aw==
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 01:13:23 -0000

Mahesh Jethanandani  writes:
> I think this argument of whether server should or should not
> create/delete NP containers is distracting from the main point of when
> NP containers should exist. In my mind, the NP container existence
> depends on whether child nodes exist or not. In the end, if child
> nodes exist, NP containers should exist (created), if they do not
> exist, the NP container should be removed.
>
> Can we agree on that? 

If the concept of a "non-presence container" makes any sense, then the
existence of an empty container must have exactly the same significance
as the non-extence of the container.

Given that, we have to make sure the protocol is consistent with that
principle.  E.g., if you ask to create an element of a non-existing NP
container, it must succeed, because asking to create an element of an
existing but empty NP container succeeds.

I don't see what all the consequences of this principle are, but if we
can't make the protocol consistent with it, then we can't properly
implement the concept of NP containers.

Dale


From nobody Sun Jul 31 18:49:28 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9C12D0A7 for ; Sun, 31 Jul 2016 18:49:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJY1cBnGSGN5 for ; Sun, 31 Jul 2016 18:49:26 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7C112B060 for ; Sun, 31 Jul 2016 18:49:26 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id l32so96724378ual.2 for ; Sun, 31 Jul 2016 18:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TF4QQZIQTIF8B4Imhv3a5Nye27K5iMBnJ5Kr662VNbg=; b=vE82Q/wyYBW76CybJBTrDhXbnXcrxuomQkvwv+MdTq5iZW1ak1pjAR/KSt5qC5XQzY IYdGrZrLiTyhwEiB2DiQ4wBJvm1UU2CcRNEL5gXOJ13YfGCuEab8pPy2VmmNNxcA4il8 wZxSmp0JEtTUka1hZGayL6TaP4r2AM7njPHLlDxuXlBOgyrkZzcbogQonjD1d0B4em/Y gmsIqWxf6V8+pZcoMUvLXHar+ev0hFmygCYOW/qiw8U9QypdZUSAqfYGPWdmD1qG5xxf 3S4AnGqkngt2ztGGmjiStq9wmZO8suwxXwTy2jmBnSJkcIEdaijWMGgW56v54A1G67xa PaWQ==
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; bh=TF4QQZIQTIF8B4Imhv3a5Nye27K5iMBnJ5Kr662VNbg=; b=Vkj9Nw58ylLXpwCzyO0LqjwC0ljfFlBjZZt+ManRPGksnpNqczeNUDWCVAoQeLaU8k JowJa38bCIK/ccQwpCCMujJZW5gOqSCFr4k57+Kravu7g4iTf7vpSCLjofGh4+bCpDuD cEfoinEN1t8cMAuyxs5afTgm1+TxXTTVq7cnoitVh8Dm2Tyskb3AsqS3QlXiZA4Z6EsQ 49FQqzzoQIKIS6KsNVJamtlZLVL/TAb1lb6vGC4YWsRw8l4f+slO+FrtJeNcCW8bh0kC xcxcRzEfnd62yndbyUOzcsu99JuJbZDDFsBAqxDcE26w5b9lwWuW9KBummesoetvnkYN I0Mg==
X-Gm-Message-State: AEkoouvwoG8sOgzYygYWYG49NzLOMAbPjJQXPZ0BFkzmTVNiosA2eFHW3Aoil/eHzsm6shJVxCrgR7aADn9Jog==
X-Received: by 10.159.36.205 with SMTP id 71mr25023063uar.121.1470016165311; Sun, 31 Jul 2016 18:49:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Sun, 31 Jul 2016 18:49:24 -0700 (PDT)
In-Reply-To: <87vazljnps.fsf@hobgoblin.ariadne.com>
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Sun, 31 Jul 2016 18:49:24 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=001a113e5dde5912300538f8cf3e
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 01:49:28 -0000

--001a113e5dde5912300538f8cf3e
Content-Type: text/plain; charset=UTF-8

Hi,

YANG 1.1 has been changed so the XPath is not really backward-compatible
with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP parent
is
instantiated.

NETCONF and RESTCONF do not say anything about the server ignoring
the rules for operation="create", operation="delete" and
default-operation="none".
IMO itr would be a really bad idea to continue spreading little protocol
details
in the YANG RFC.  People might read the protocol spec and (correctly) assume
that the protocol does not trat NP containers special at all.

If anything, the sentence about MAY delete needs to be removed because
it is inconsistent with the XPath (always exists).


Andy


On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley  wrote:

> Mahesh Jethanandani  writes:
> > I think this argument of whether server should or should not
> > create/delete NP containers is distracting from the main point of when
> > NP containers should exist. In my mind, the NP container existence
> > depends on whether child nodes exist or not. In the end, if child
> > nodes exist, NP containers should exist (created), if they do not
> > exist, the NP container should be removed.
> >
> > Can we agree on that?
>
> If the concept of a "non-presence container" makes any sense, then the
> existence of an empty container must have exactly the same significance
> as the non-extence of the container.
>
> Given that, we have to make sure the protocol is consistent with that
> principle.  E.g., if you ask to create an element of a non-existing NP
> container, it must succeed, because asking to create an element of an
> existing but empty NP container succeeds.
>
> I don't see what all the consequences of this principle are, but if we
> can't make the protocol consistent with it, then we can't properly
> implement the concept of NP containers.
>
> Dale
>

--001a113e5dde5912300538f8cf3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

YANG 1.1 has been changed so the XP=
ath is not really backward-compatible
with YANG 1.0.=C2=A0 In YAN=
G 1.1 NP-containers always exist if the non-NP parent is
instanti=
ated.

NETCONF and RESTCONF do not say anything abo=
ut the server ignoring
the rules for operation=3D"create&quo=
t;, operation=3D"delete" and default-operation=3D"none"=
.
IMO itr would be a really bad idea to continue spreading little=
 protocol details
in the YANG RFC.=C2=A0 People might read the pr=
otocol spec and (correctly) assume
that the protocol does not tra=
t NP containers special at all.

If anything, the s=
entence about MAY delete needs to be removed because
it is incons=
istent with the XPath (always exists).


<=
div>Andy


On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <worley=
@ariadne.com> wrote:
Mahesh=
 Jethanandani <mjethanandani@=
gmail.com> writes:

> I think this argument of whether server should or should not

> create/delete NP containers is distracting from the main point of when=


> NP containers should exist. In my mind, the NP container existence

> depends on whether child nodes exist or not. In the end, if child

> nodes exist, NP containers should exist (created), if they do not

> exist, the NP container should be removed.

>

> Can we agree on that?



If the concept of a "non-presence container" makes any sense, the=
n the

existence of an empty container must have exactly the same significance

as the non-extence of the container.



Given that, we have to make sure the protocol is consistent with that

principle.=C2=A0 E.g., if you ask to create an element of a non-existing NP=


container, it must succeed, because asking to create an element of an

existing but empty NP container succeeds.



I don't see what all the consequences of this principle are, but if we<=
br>
can't make the protocol consistent with it, then we can't properly<=
br>
implement the concept of NP containers.



Dale





--001a113e5dde5912300538f8cf3e--


From nobody Sun Jul 31 20:36:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BFD127071 for ; Sun, 31 Jul 2016 20:36:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg1L25GxhVmj for ; Sun, 31 Jul 2016 20:35:59 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154A212D177 for ; Sun, 31 Jul 2016 20:35:59 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id l32so97814913ual.2 for ; Sun, 31 Jul 2016 20:35:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6TrzHSu+eWar4X/YE5QdNcPdFCk1DRgPh+0oSnIHTew=; b=WVBaaJst5u1ZKvvrmws1K0dYQmbMlsOYdEVYKZkzjZVFPHJMibxqujbUAMsw1KkBmX tctad42uDL5OLcy9VQ9KvlWEAKJVdYzV94HfwKbXe0hjo9w4AuxEAJY4/68HrcoEhw23 lnWl6HgKeul2af+Bu3ELEAFiwoeYa9Y00+stmQ1wmp4SaJIW6PPL9V4DzIh5K/QXY1F5 ir67aLa4lWU+t2ZkMPrvISbd5vs6dOwKXzMN1BENArv2zstUU2Oeyh3LI1uTVsNFrXvo S69JRWGhCDYGR59InvCzt9id4y9EmbgT4Oox/9RgsF51Aysfc4N+p+XouGUimE/Po2sF +VSw==
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; bh=6TrzHSu+eWar4X/YE5QdNcPdFCk1DRgPh+0oSnIHTew=; b=PP/nve00xQgTj0a1gpUfM3iwz4Nr8jqJs8TS3P8VszuUqqoL2QBSzC7E5u1xFruYAl r9iYMQDDM1YjejzSy7mjMRsSXqtYpN84KJ2Gx4iiuJcKcSVKN9XQ1lio5rTZ1rYyqMQz F5dgSK0dlm9MLjkZ1OoMtyNm7Z4GsD3zWxGRnWM6RWccICXEbJ5YuXfSBEFhxNzR8bCj FSB9orBuNTt8V1QqxWKrYLHQKzEEnpEbdSuUy90kVtwO2GhhzbkIwxxuB4DwLjP2/7cu U6U3KFpmBkJWNL3L4OZk0lmlzVMF1l4VxlDJA/bSUO+HTHi9QLDPAIBV2sLghZt+j0y5 KlyA==
X-Gm-Message-State: AEkooutoaAd/GblGoIAuU2yeGRgFMTNJkAsuFV8yf83GtV4RMmx1kJAdW0kb1Ax4kEYPTeQHUtOr+C4dqwinFg==
X-Received: by 10.159.35.112 with SMTP id 103mr24825245uae.55.1470022557742; Sun, 31 Jul 2016 20:35:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Sun, 31 Jul 2016 20:35:56 -0700 (PDT)
In-Reply-To: <87y44hjq7d.fsf@hobgoblin.ariadne.com>
References: <87y44hjq7d.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Sun, 31 Jul 2016 20:35:56 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=001a113ab81a5dd5d90538fa4c56
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] IETF Last Call Gen-ART review of draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 03:36:08 -0000

--001a113ab81a5dd5d90538fa4c56
Content-Type: text/plain; charset=UTF-8

Hi,

This will get added to the github issue list.

I am on vacation next week so edits will not be done for at least 2 weeks.


Andy


On Sun, Jul 31, 2016 at 5:19 PM, Dale R. Worley  wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> .
>
> Document: review-draft-ietf-netconf-restconf-15
> Reviewer: Dale R. Worley
> Review Date: 29 July 2016
> IETF LC End Date: 3 August 2016
> IESG Telechat date: "Not yet"
>
> Summary:
>
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> * Technical nits
>
> - In a few places, returned data can include URIs that are intended to
> be usable by the client to retrieve information from the Restconf
> server.  These places include the  element for accessing an
> event stream, the Location header of POST responses, and the URLs for
> retrieving schema resources (section 3.7).  The problem
> is that implementing this assumes that the server knows a host
> identifier (domain name or address) that the client can use to access
> the server.  In general, given the ubiquity of NATs, the server
> doesn't know this.
>
> It seems to me that the two possible solutions are for the server to
> be able to return a URI *relative reference* or for the server to use
> as the host-part of the URL the value in the Host header of the
> request (which perforce the server knows the client can use to access
> the server).  Perhaps this is a known problem with a known solution
> and so the draft doesn't bother to mention it.  Then again, perhaps in
> practice the clients and the server are in region of the network
> containing no internal NATS, and the problem does not arise.
>
> But it seems to me that this could be a very general problem for
> implementers and they should be instructed how to deal with it.  I
> suspect that the authors know the intended resolution of this issue,
> but it would help if the resolution was stated explicitly.
>
> - Does XRD (RFC 6415) admit relative links as values of the href
> attribute of the Link element?  Relative links are not usually
> considered to be "URIs", but rather "URI-references" (RFC 3986 section
> 4.1), and RFC 6415 uses "URI" consistently, not "URI-reference".
> Also, all examples in RFC 6415 show complete URIs.  If the href
> attributes have to be full URIs, then the problem with host
> identifiers described above also arises.
>
> * General issues
>
> - Might it be useful to consistently use a trailing-backslash
> convention?  There are 17 places that state "lines wrapped for display
> purposes only".  And there are places where lines are wrapped without
> this message, e.g., section 6.2.  It might be better for the reader to
> replace all of these messages with a single statement at the top:
>
>    When a line ends with backslash as the last (non-whitespace)
>    character, it is wrapped for display purposes.  It is to be
>    considered to be joined to the next line by deleting the backslash,
>    the following line break, and the leading whitespace of the next
>    line.
>
> - There is a general point regarding the interpretation of data resource
> URLs.  Items in leaf-lists and lists that are not configuration data
> need not have unique values/keys, and so a URL that selects nodes
> within a leaf-list/list by providing a value may select multiple
> target nodes.  The consequences of this do not seem to be explicitly
> pointed out to the reader in any place.
>
> In regard to retrieval requests (GET or HEAD), this is handled
> correctly:  If the response is to be formatted in XML, the request
> fails, because XML has no method to return multiple values.  If the
> response is to be formatted in JSON, the request succeeds, because
> JSON can return multiple values.  (As stated in section 4.3.)
>
> All other requests methods modify the target resource(s), and
> therefore cannot be directed to non-configuration data.  But
> configuration data leaf-lists/lists must have unique values/keys, so a
> URL that identifies modifiable resources must identify a unique
> resource.  Most of the text conforms to this fact, but in section 4.7
> (regarding DELETE) is:
>
>    If the target resource represents a YANG leaf-list or list, then the
>    DELETE method SHOULD NOT delete more than one such instance.
>
> It seems to me that this situation cannot arise.
>
> I don't think this issue requires much change to the text.  There is
> the change to section 4.7 listed above, and it seems like it would be
> useful to add a general warning in section 3.5.3:
>
>     A URI that specifies list/leaf-list values may contain a value
>     that identifies multiple data nodes.  Since duplicate values are
>     not permitted in configuration data, any such URI must identify
>     non-configuration data.  A request with such a URI is processed
>     according to the specifications of the request method; in
>     particular, since non-configuration data cannot be edited, a
>     request with a method that changes data will necessarily be
>     rejected if the URI specifies multiple data nodes.
>
> - The term "resource type" is used frequently but not defined.  It
> seems that the set of all resources, i.e., valid URLs in the Restconf
> interface, is divided into classes, each of which has a distinct
> "resource type", and a distinct set of behaviors.  It would be very
> useful to the reader to state this explicitly and list the resource
> types.  The text almost does this implicitly, as the resource types
> correspond fairly well to the subsections of section 3, though only
> sections 3.1, 3.4, 3.5, 3.6, 3.7, and 3.8 correspond to resource
> types.
>
> See also the chart listing three resource types (Datastore, Data, and
> Operation) in section 4.4.
>
> There seem to be a few places where "resource media type" is used to
> mean the same thing as "resource type".  It seems like it should be
> replaced by "resource type".
>
> - YANG data template
>
> I think there is an important concept buried in the term "YANG data
> template", but it isn't stated exactly anywhere, and it's not clear to
> me precisely what it is.  There is an entry in section 1.1.5, "Terms":
>
>    o  YANG data template: a schema for modeling a conceptual data
>       structure in an encoding-independent manner.  It is defined with
>       the "yang-data" extension, found in Section 8.  It has a
>       representation with the media-type "application/yang-data" or
>       "application/yang-data+json".
>
> I can't figure out the exact relationship between "YANG data
> template", "something defined with the yang-data extension", "the
> schema tree of a module", and "data that implicitly has
> representations using XML and JSON".
>
> The question of what is a "YANG data template" also interacts with the
> question of what the purpose of the yang-data extension is.
>
> I'm sure that the authors at least have an intuitive understanding of
> how these concepts interrelate, but it doesn't seem to me that any of
> this is laid out clearly for the naive reader.
>
> I think this can be resolved by getting clear answers to these
> questions:
>
> -- Does the word "template" have a specific meaning?
>
> The word "template" does not appear in
> draft-ietf-netmod-rfc6020bis-14.  It doesn't seem to be equivalent to
> "schema tree", because that's defined as "The definition hierarchy
> specified within a module.", i.e., the entire tree defined by a
> module.  Template seems to be equivalent to "the subtree rooted at a
> first-level schema node".
>
> It may be that the phrase "YANG data template" would be better
> replaced by some other phrase.
>
> -- What is the significance of the phrase "a schema for modeling a
> conceptual data structure in an encoding-independent manner"?
>
> By assumption, all of the data in the implemented modules exists in an
> encoding-independent manner, and the mere fact that it's accessible
> via RESTCONF defines that it can be represented in XML and JSON.
>
> -- What exactly does the yang-data extension statement do?
>
> It seems to me that the draft doesn't need the extension.  For
> example, in section 7.1 regarding error responses, the current text
> is:
>
>    When an error occurs for a request message on any resource type, and
>    the status code that will be returned is in the "4xx" range (except
>    for status code "403 Forbidden"), then the server SHOULD send a
>    response message-body containing the information described by the
>    "yang-errors" YANG template definition within the "ietf-restconf"
>    module, found in Section 8.
>
> But it seems to me that it would suffice to say 'The response
> message-body contains a representation of an instance of the "errors"
> container in the "ietf-restconf" module find in Section 8 (using the
> module name "ietf-restconf" and the namespace
> "urn:ietf:params:xml:ns:yang:ietf-restconf").'
>
> So what is the particular value of the yang-data extension and why is
> it not needed for schema trees defined in ordinary implemented
> modules?
>
> -- While we're at it, where is the specification that all Yang data
> has representations in XML and JSON?
>
> Clearly there must be such a specification, as that's necessary for
> Restconf to work at all, but I've overlooked it.
>
> - There seem to be six statements in the draft that the fragment field
> in RESTCONF resource URIs has no defined purpose, either for some set
> of resources or for all resources.  (sections 3.4, 3.5, 3.6, 3.8, 5.1
> (twice)  But of course, the fragment identifier is never presented to
> the HTTP/HTTPS server for the resource -- see RFC 7230 section 5.1:
>
>    The target URI excludes the reference's fragment component, if any,
>    since fragment identifiers are reserved for client-side processing
>    ([RFC3986], Section 3.5).
>
> It seems like a single statement of this fact would be sufficient, and
> that section 5.1 is a natural place to put it, along with removing the
> "fragment" field from the illustration of an HTTP request's
> request-line:
>
>          //?#
>
>           ^       ^        ^       ^         ^
>           |       |        |       |         |
>         method  entry  resource  query    fragment
>
>           M       M        O        O         I
>
> However, the discussion of fragment identifiers in the media type
> definitions is correct and proper.
>
> - There seems to be a general inconsistency in indentation -- see the
> end of the review for a list showing how each HTTP example is
> indented.
>
> - There should be only one space between the request URI and
> "HTTP/1.1".  (RFC 7230 section 3.1.1)  This is done incorrectly in:
>
>     3.1.  Root Resource Discovery
>           GET /top/restconf/operations  HTTP/1.1
>     3.3.1.  {+restconf}/data
>            ?content=nonconfig  HTTP/1.1
>     3.3.3.  {+restconf}/yang-library-version
>        GET /restconf/yang-library-version  HTTP/1.1
>     4.3.  GET
>           library/artist=Foo%20Fighters/album=Wasting%20Light  HTTP/1.1
>     4.4.2.  Invoke Operation Mode
>           POST /restconf/operations/example-jukebox:play   HTTP/1.1
>     4.5.  PUT
>               library/artist=Foo%20Fighters/album=Wasting%20Light
>  HTTP/1.1
>            library/artist=Foo%20Fighters/album=Wasting%20Light   HTTP/1.1
>     D.1.1.  Retrieve the Top-level API Resource
>        GET /restconf   HTTP/1.1
>     D.1.3.  Retrieve The Server Capability Information
>            capabilities  HTTP/1.1
>     D.2.1.  Create New Data Resources
>            library/artist=Foo%20Fighters  HTTP/1.1
>     D.3.5.  "point" Parameter
>               Wasting%20Light%2Fsong%3DBridge%20Burning   HTTP/1.1
>
> - Percent-encoding
>
> There are some details of percent-encoding that aren't fully
> specified.  Percent-encoding is described in sections 3.5.3 and 5.1,
> so I've consolidated the discussion here.
>
> One is that the Yang string character set is Unicode, so to fully
> specify how percent-encoding is done, we have to specify a character
> representation to map Unicode characters into octets, after which
> percent-encoding can be done.  These days the expected encoding for
> Unicode is UTF-8, and percent-encoding using the UTF-8 representation
> is described in the final paragraph of section 2.5 of RFC 3986.  This
> means that the item in section 3.5.3 should be changed from
>
>    o  The key value is specified as a string, using the canonical
>       representation for the YANG data type.  Any reserved characters
>       MUST be percent-encoded, according to [RFC3986], section 2.1.
>
> to
>
>    o  The key value is specified as a string, using the canonical
>       representation for the YANG data type.  Any reserved characters
>       MUST be percent-encoded, according to [RFC3986], sections 2.1 and
>       2.5.
>
> and section 5.1 should be changed from
>
>    Any reserved characters MUST be percent-encoded, according to
>    [RFC3986], sections 2.1 and 2.5.
>
> - Must "," be percent-encoded when it appears in the key value for a
> leaf-list node, given that a leaf-list path component cannot have more
> than one key values?  See the comments for section 3.5.3.
>
> - There are a number of questions regarding the ABNF in section
> 3.5.3.1 and precisely which URLs must conform to that syntax.  See the
> comments for that section.
>
> - Is the ietf-restconf module listed in
> {+restconf}/data/ietf-restconf-monitoring:modules-state/module?  I can
> see that this could be argued either way.  See the comments for
> section 10.1.1.
>
> - Generally, a colon in JSON is formatted with one space before and
> one space after.  But these lines are formatted differently:
>
>             "@mtu": {
>         "ietf-restconf:errors": {
>               "error-type": "protocol",
>               "error-tag": "lock-denied",
>               "error-message": "Lock failed, lock already held"
>         "ietf-restconf:restconf": {
>         "ietf-yang-library:modules-state": {
>           "module-set-id": "5479120c17a619545ea6aff7aa19838b036ebbd7",
>           "ietf-yang-library:modules-state": {
>
> * Nits
>
> Table of Contents
>
>    ...
>    8.  RESTCONF module . . . . . . . . . . . . . . . . . . . . . . .  66
>
> This should be "RESTCONF Module".
>
> 1.  Introduction
>
>    If a RESTCONF server is co-located with a NETCONF server, then there
>    are protocol interactions to be considered, as described in
>    Section 1.4.
>
> This is a bit vague, as it doesn't specify with *what* protocols there
> are interactions.  But this is obvious to most readers, as it's
> concerned with interaction with the Netconf protocol.  But it's not
> obvious to readers who don't know Netconf, because the preceding text
> only describes Netconf as a system of datastore semantics.  So I think
> this could be clarified by modifying this sentence:
>
>    NETCONF defines configuration datastores and a set of Create,
>    Retrieve, Update, Delete (CRUD) operations that can be used to access
>    these datastores.
>
> to
>
>    NETCONF defines configuration datastores; a set of Create,
>    Retrieve, Update, Delete (CRUD) operations that can be used to access
>    these datastores; and a protocol for invoking those operations.
>
> and modifying the above sentence to
>
>    If a RESTCONF server is co-located with a NETCONF server, then there
>    are protocol interactions with the NETCONF protocol, which are
> described in
>    Section 1.4.
>
> and changing the first sentence/paragraph of 1.4 to
>
>    RESTCONF can be implemented on a device that supports the NETCONF
> protocol.
>
> --
>
>    Data-model specific RPC operations defined with the YANG "rpc" or [...]
>
> I think this should start "Data-model-specific", as all of that phrase
> is an adjective that modifies "RPC".  Similarly in the following
> sentence, and other places in the draft.
>
> 1.1.5.  Terms
>
> The term "operation" is used in at least three senses:
>
> - HTTP request methods (e.g., the title of section 4)
> - abstract CRUD operations
> - RPC operations, viz., from the Yang "rpc" and "action" statements.
>
> and also within
>
> - edit operation: a RESTCONF operation on a data resource using
>   either a POST, PUT, PATCH, or DELETE method.
>
> You need to check that you have ways to specify each of these, and
> that all uses of "operation" are unambiguous.  It might be useful to
> mention this ambiguity in the lexicon item for "operations".
>
>    o  API resource: a resource that models the RESTCONF entry point and
>       the sub-resources to access YANG-defined content.  It is defined
>       with the YANG data template named "yang-api" in the
>       "ietf-restconf" module.
>
> This should probably start "the resource that ...", as there is only one.
>
>    o  data resource: a resource that models a YANG data node.  It is
>       defined with YANG data definition statements, and YANG containers,
>       leafs, leaf-list entries, list entries, anydata and anyxml nodes
>       can be data resources.
>
> It seems redundant to say "and YANG containers, leafs, leaf-list
> entries, list entries, anydata and anyxml nodes can be data
> resources.", because that is the whole list of YANG entities that can
> be data nodes.  Worse, if a new YANG data node type is added, this
> list will have to be updated.  Would it be acceptable to delete the
> second sentence?
>
>    o  datastore resource: a resource that models a programmatic
>       interface to NETCONF datastores.
>
> This should probably start "the resource that ...", as there is only one.
>
> I think "NETCONF datastores" should be "the NETCONF datastore", since a
> datastore resource must model exactly one NETCONF datastore.
>
>    o  event stream resource: This resource represents an SSE (Server-
>       Sent Events) event stream.  The content consists of text using the
>       media type "text/event-stream", as defined by the SSE
>       [W3C.REC-eventsource-20150203] specification.  Each event
>       represents one  message generated by the server.  It
>       contains a conceptual system or data-model specific event that is
>       delivered within an event notification stream.  Also called a
>       "stream resource".
>
> What is a " message"?  Is  a concept from the
> NETCONF protocol?  It is not used elsewhere in the draft.
>
> Also, an event does not represent a notification message, a
> notification message represents an event.
>
> The "It" in "It contains a conceptual system" seems ambiguous.  Do you
> mean "Each message contains ..."?
>
> Also, it seems that "system or data-model specific event" would be
> clearer as "system event or data-model-specific event", to make it
> clear that "system" is an adjective.
>
>    o  patch: a generic PATCH request on the target datastore or data
>       resource.  The media type of the message-body content will
>       identify the patch type in use.
>
> Does the "generic" add meaning here, or can it be omitted without
> loss?
>
>    o  plain patch: a specific PATCH request type, defined in
>       Section 4.6.1, that can be used for simple merge operations.  It
>       has a representation with the media-type "application/yang-data"
>       or "application/yang-data+json".
>
> I don't think that "PATCH request type" is defined.  Also the use of
> "representation" is odd.  Perhaps:
>
>    o  plain patch: a specific PATCH request type, defined in
>       Section 4.6.1, that can be used for simple merge operations.  It
>       is specified by a request Content-Type of "application/yang-data"
>       or "application/yang-data+json".
>
> --
>
>    o  RESTCONF capability: An optional RESTCONF protocol feature
>       supported by the server, which is identified by an IANA registered
>       NETCONF Capability URI, and advertised with an entry in the
>       "capability" leaf-list in Section 9.3.
>
> Probably should be "[...] leaf-list defined in Section 9.3.".
>
>    o  RESTCONF client: a client which implements the RESTCONF protocol.
>       Also called "client".
>
> It seems to me that the "Also called ..." clauses (for "client",
> "server", and "stream resource") should be turned into stand-alone
> entries, as otherwise it's difficult to find the definition of
> "client", etc.
>
>    o  schema resource: a resource that has a representation with the
>       media type "application/yang".  The schema resource is used by the
>       client to retrieve the YANG schema with the GET method.
>
> Is the defining characteristic of a schema resource that it 'has a
> representation with the media type "application/yang"'?  Or is its
> defining characteristic the fact that "the client [can use it] to
> retrieve the YANG schema"?  If the latter, I suggest reversing the
> two sentences:
>
>    o  schema resource: a resource that can be used by the client to
>       retrieve a YANG schema.  It has a representation with the
>       media type "application/yang".
>
> --
>
> 1.2.  Subset of NETCONF Functionality
>
>    The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data
>    resources represented by YANG data models.  These basic edit
>    operations allow the running configuration to be altered in an all-
>    or-none fashion.
>
> What is the meaning of "all-or-none" here?  Initially, I though it
> meant that the actions were atomic, in that they either succeeded
> completely or had no effect, but it might be referring to the fact
> that RESTCONF cannot assemble a transaction from several elementary
> editing operations.
>
>    RESTCONF is not intended to replace NETCONF, but rather provide an
>    additional interface that follows Representational State Transfer
>    (REST) principles [rest-dissertation], and is compatible with a
>    resource-oriented device abstraction.
>
> Given the first sentence of section 1, the major goal of RESTCONF
> seems to be to be HTTP-based, so it might be more accurate to say
> "... to provide an HTTP interface that follows ...".
>
> Could "compatible with a resource-oriented device abstraction" be more
> usefully expressed as "compatible with the NETCONF datastore model"?
>
>       +-----------+           +-----------------+
>       |  Web app  | <-------> |                 |
>       +-----------+   HTTP    | network device  |
>                               |                 |
>       +-----------+           |   +-----------+ |
>       |  NMS app  | <-------> |   | datastore | |
>       +-----------+  NETCONF  |   +-----------+ |
>                               +-----------------+
>
> The figure does not show that the "Web app" is using RESTCONF -- it's
> an illustration of the use of RESTCONF that doesn't specify where
> RESTCONF is used!  Perhaps change to "RESTCONF over HTTP"?
>
> "NMS" is used nowhere else in the draft.  I assume it means "network
> management system".  Perhaps all readers are expected to know that.
> Otherwise, "NETCONF client" would be better.  (And can't a network
> management system use Restconf?)
>
> 1.3.  Data Model Driven API
>
>    Using YANG, a client can predict all management resources, much like
>    using URI Templates [RFC6570], but in a more holistic manner.
>
> Better,
>
>    Knowing the YANG modules describing the server's data model, a
>    client can derive all management resource URLs and the proper
>    structure of all RESTCONF requests and responses.
>
> --
>
>    RESTCONF provides the YANG module capability information supported by
>    the server, in case the client wants to use it.  The URIs for data-
>    model specific RPC operations and datastore content are predictable,
>    based on the YANG module definitions.
>
> I've folded the second sentence of this passage into the previous
> edit.  It seems like the first sentence could be phrased more simply,
> "RESTCONF allows the client to retrieve the list of YANG modules
> supported by the server."  Actually, I'm not sure that's correct; what
> is "the YANG module capability information"?  The only use of
> "capability" in draft-ietf-netmod-rfc6020bis-14 is for the capability
> identifier URI urn:ietf:params:netconf:capability:yang-library:1.0,
> which is mandatory to implement (since there is no other version
> defined).
>
> You might want to note here that the server might provide the
> definitions of the modules that it supports.  E.g., "The server can
> optionally support retrieval of the YANG modules it supports; see
> Section 3.7."
>
>    The RESTCONF datastore editing model is simple and direct, similar to
>    the behavior of the :writable-running capability in NETCONF.  Each
>    RESTCONF edit of a datastore resource is activated upon successful
>    completion of the transaction.
>
> I don't know the exact terminology that is used in this field, but I
> think the final word would better be "edit".  The problem is that
> "transaction" is used in the database world to mean everything
> starting with the first edit operation and ending with the commit to
> permanent storage.  With that definition, the "completion of the
> transaction" happens only after the commit is finished.  But in this
> context, the commit is the same as "a datastore resource is
> activated"!
>
> 1.4.  Coexistence with NETCONF
>
> It seems to me that the section would more accurately be described as
> "Datastore and transaction management".
>
>    If the device supports :startup, the device MUST automatically update
>    the non-volatile "startup datastore", after the running datastore has
>    been updated as a consequence of a RESTCONF edit operation.
>
> Is there a reason that there are double-quotes around "startup
> datastore"?  I do not see that usage in RFC 6241.
>
> 1.5.  RESTCONF Extensibility
>
>    This document defines version 1 of the RESTCONF protocol.  If a
>    future version of this protocol is defined, then that document will
>    specify how the new version of RESTCONF is identified.  It is
>    expected that a different entry point {+restconf2} would be defined.
>
> The symbol "{+restconf2}" has no defined meaning.  I think you want
> "It is expected that a different entry point will be used, which will
> be located using a different link relation (Section 3.1)."
>
>       Response
>       --------
>       HTTP/1.1 200 OK
>       Content-Type: application/xrd+xml
>       Content-Length: nnn
>
>    
>        
>        
>    
>
> The response message-body isn't indented to the same margin as the
> headers.
>
>    Typically this extension mechanism is used to identify optional query
>    parameters but it is not limited to that purpose.
>
> Should this say "optional query parameters that are supported"?  Also,
> could "Typically" be improved as "Currently"?
>
> 2.2.  HTTPS with X.509v3 Certificates
>
>    The use the X.509v3 based certificates is consistent with NETCONF
>    over TLS [RFC7589].
>
> There is a syntax error in the first few words of this sentence.
>
>    The RESTCONF client MUST either use X.509 certificate path validation
>    [RFC5280] to verify the integrity of the RESTCONF server's TLS
>    certificate, or match the presented X.509 certificate with locally
>    configured certificate fingerprints.
>
>    The presented X.509 certificate MUST also be considered valid if it
>    matches a locally configured certificate fingerprint.  If X.509
>    certificate path validation fails and the presented X.509 certificate
>    does not match a locally configured certificate fingerprint, the
>    connection MUST be terminated as defined in [RFC5246].
>
> The second sentence seems to be redundant with the second clause of
> the first sentence.  (Or is it intended that the client MUST be
> configurable with fingerprints?)  The last sentence seems to be
> verbose; it should be possible to say "If the certificate cannot be
> validated by either method, ...".
>
> 3.  Resources
>
>    A resource has a representation associated with a media type
>    identifier, as represented by the "Content-Type" header in the HTTP
>    response message.
>
> This seems awkward.  Perhaps:
>
>    A resource has one or more representations, each associated with a
>    different media type.  When a representation of a resource is sent
>    in an HTTP response message, the associated media type is given in
>    the "Content-Type" header.
>
> --
>
>    All RESTCONF resource types are defined in this document except
>    specific datastore contents, RPC operations, and event notifications.
>
> This depends on exactly what "resource type" means.  As discussed at
> the beginning, that phrase seems to mean a small, finite number of
> resource classes that are all defined in this document.  I think what
> this sentence is trying to get at is that the specific resources of a
> particular server that are in each of the resource type classes is
> determined by the set of modules the server implements.  But that
> isn't what the sentence says (assuming I'm correct about what
> "resource type" means).
>
>    The syntax and semantics for these resource types are defined in YANG
>    modules.
>
> Perhaps "... are defined in the YANG modules that the server
> implements.".
>
>    The RESTCONF protocol does not include a data resource discovery
>    mechanism.  Instead, the definitions within the YANG modules
>    advertised by the server are used to construct a predictable
>    operation or data resource identifier.
>
> It seems like "predictable" is redundant given the use of "construct".
>
> 3.1.  Root Resource Discovery
>
>    After discovering the RESTCONF API root, the client MUST prepend it
>    to any subsequent request to a RESTCONF resource.
>
> It's not actually prepended to the *request*, it's the initial part of
> the path of the request URI:
>
>    The RESTCONF API root is used as the initial part of the path of
>    the request URI of any request to a RESTCONF resource.
>
> Because of the resource discovery system, any given host:port can
> support only one RESTCONF server.  This means that a particular host
> is not expected to support an arbitrarily large number of RESTCONF
> servers, as each server must use a different port.  I doubt this is a
> practical limitation for the intended usages, but it's probably worth
> mentioning in the Introduction.
>
> 3.3.  API Resource
>
>    +--rw restconf
>       +--rw data
>       +--rw operations
>       +--ro yang-library-version
>
> That seems to imply that the root resource has the name "restconf" (or
> perhaps that the last component of its name is "restconf").  I think
> you could be more accurate (with some abuse of notation) by:
>
>    +--rw {+restconf}
>       +--rw data
>       +--rw operations
>       +--ro yang-library-version
>
> Section 1.7 says 'Ellipsis ("...") stands for contents of subtrees
> that are not shown.', but ellipsis is not exploited here to clarify
> where in the tree additional nodes will be:
>
>    +--rw {+restconf}
>       +--rw data
>       |  ...
>       +--rw operations?
>       |  ...
>       +--ro yang-library-version
>
> Section 3.3.2 states that "operations" is optional, so there should be
> a "?" after "operations".
>
>    The "yang-api" YANG data template is defined with the "yang-data"
>    extension in the "ietf-restconf" module, found in Section 8.  It is
>    used to specify the structure and syntax of the conceptual child
>    resources within the API resource.
>
> I think this would be clearer if you said '... defined using the
> "yang-data" extension', and "It specifies the structure and syntax
> ...".
>
> 3.4.  Datastore Resource
>
>    The "{+restconf}/data" subtree represents the datastore resource
>    type, which is a collection of configuration data and state data
>    nodes.
>
> Shouldn't this be "... represents the datastore, which is ..."?
>
>    This resource type is an abstraction of the system's underlying
>    datastore implementation.  It is used to simplify resource editing
>    for the client.  The RESTCONF datastore resource is a conceptual
>    collection of all configuration and state data that is present on the
>    device.
>
> The first sentence is extremely clear.  The second sentence is odd;
> doesn't it mean "The client uses it to edit resources."?  The third
> sentence seems to be a longer statement of the first sentence, given
> what the datastore is.
>
>    Configuration edit transaction management and configuration
>    persistence are handled by the server and not controlled by the
>    client.  A datastore resource can be written directly with the POST
>    and PATCH methods.  Each RESTCONF edit of a datastore resource is
>    saved to non-volatile storage by the server, if the server supports
>    non-volatile storage of configuration data.
>
> The second sentence makes sense in this context.  The first and third
> sentences are datastore management, which is discussed in section 1.4.
>
> 3.4.1.  Edit Collision Detection
>
>    Two "edit collision detection" mechanisms are provided in RESTCONF,
>    for datastore and data resources.
>
> Why are there double-quotes around "edit collision detection"?
>
> There seems to be a third mechanism:  if the datastore is locked, the
> request gets a 409 response (section 1.4).  Though maybe that's more
> "collision prevention" than "collision detection".
>
> 3.4.1.1.  Timestamp
>
>    If the RESTCONF server is colocated with a NETCONF server, then the
>    last-modified timestamp MUST represent the "running" datastore.
>
> "represent" isn't the right word here.  Perhaps "... MUST be that of
> ...".  Of course, this fact is implicit in the Restconf definition,
> because Restconf provides access only to the running datastore, but
> it's worth warning the implementer explicitly.
>
> 3.4.1.2.  Entity tag
>
>    A unique opaque string is maintained and the "ETag" ([RFC7232],
>    Section 2.3) header is returned in the response for a retrieval
>    request.  The "If-Match" header can be used in edit operation
>    requests to cause the server to reject the request if the resource
>    entity tag does not match the specified value.
>
> It seems you want 2119 language here:
>
>    The server MUST maintain a unique opaque entity-tag for the
>    datastore resource and MUST return it in the "ETag" ([RFC7232],
>    Section 2.3) header in the response for a retrieval request.  The
>    client MAY use an "If-Match" header in edit operation requests to
>    cause the server to reject the request if the resource entity tag
>    does not match the specified value.
>
> An interesting point that you may want to warn the reader about is
> that the entity-tag encodes not only the data in the resource but also
> its representation; different representations (XML vs. JSON) must have
> different entity-tags.  (RFC 7323 section 2.3)
>
>    If the RESTCONF server is colocated with a NETCONF server, then this
>    entity tag MUST represent the "running" datastore.
>
> "represent" isn't the right word here.  Perhaps "... MUST be that of ...".
>
> 3.4.1.3.  Update Procedure
>
> It seems like the substantial part of this section is "Changes to
> configuration data resources affect the timestamp and entity tag to
> ... the datastore resource."  The rest of what it says is more fully
> described in section 3.5.  It seems that the real point is to state
> that changing any of the configuration resources changes the
> timestamp/ETag of the datastore resource, which is more or less
> understood, given that the datastore has a timestamp/ETag.  But it
> seems that this could be more clearly said in 3.4.1:
>
>    Two "edit collision detection" mechanisms are provided in RESTCONF
>    for the datastore:  a timestamp and an ETag.  (These may also be
>    provided for data resources; see Section 3.5.)  Any change to
>    configuration data resources updates the timestamp and entity tag
>    of the datastore resource.
>
> 3.5.  Data Resource
>
>    A configuration data resource can be altered by the client with some
>    or all of the edit operations, depending on the target resource and
>    the specific operation.  Refer to Section 4 for more details on edit
>    operations.
>
> It seems like this paragraph is largely redundant.
>
> 3.5.3.  Encoding Data Resource Identifiers in the Request URI
>
>    In YANG, data nodes are identified with an absolute XPath expression,
>    defined in [XPath], starting from the document root to the target
>    resource.  In RESTCONF, URI-encoded path expressions are used
>    instead.
>
> I think "are identified" should be "can be identified" -- relative
> XPath is also allowed in Yang.
>
>    If a node in the
>    path is defined in another module than its parent node, then module
>    name followed by a colon character (":") is prepended to the node
>    name in the resource identifier.
>
> That should start "If a node in the path is defined in another module
> than its parent node, or its parent is the datastore, then module
> ...".
>
> The following item appears in the list concerning list nodes:
>
>    o  The key value is specified as a string, using the canonical
>       representation for the YANG data type.  Any reserved characters
>       MUST be percent-encoded, according to [RFC3986], section 2.1.
>
> This fact also needs to be specified for leaf-list nodes, so either
> this item should be duplicated into the list of items for leaf-list
> nodes, or it should be pulled out as a top-level paragraph.
>
> The reader needs to be warned that in the the character "," in a key
> value must also be percent-encoded, despite that it is not considered
> "reserved" in any definition of URL.
>
> This leads to a technical nit:  Must "," be percent-encoded when it
> appears in the key value for a leaf-list node, given that a leaf-list
> path component cannot have more than one key values?  (Whether this is
> specified as true or false is not important, but the standard needs to
> fix the requirement.)
>
>    Resource URI values returned in Location headers for data resources
>    MUST identify the module name as specified in
>    [I-D.ietf-netmod-yang-json], even if there are no conflicting local
>    names when the resource is created.  This ensures the correct
>    resource will be identified even if the server loads a new module
>    that the old client does not know about.
>
> It's not clear that this restriction adds anything.  Module names are
> required in resource URIs already, by "If a node in the path is
> defined in another module than its parent node, [or its parent is the
> datastore,] then module name followed by a colon character (":") is
> prepended to the node name in the resource identifier."
>
> 3.5.3.1.  ABNF For Data Resource Identifiers
>
>        api-path = "/"  |
>                   ("/" api-identifier
>                     0*("/" (api-identifier | list-instance )))
>
> I'm assuming there that  is the syntax for the path *within*
> the API's section of the URL space, that is, the string which is
> appended to the entry point {+restconf}.  This seems necessary, as
> otherwise the segments of the entry point path would have to conform
> to , and that restriction seems pointless.  But this
> point should probably be clarified in the text.
>
> It seems that this ABNF only applies to the paths of data resource
> identifiers, not other resource types.  But in that case, why does the
> syntax allow "/" alone, which isn't the path of a data resource?
> Indeed, a data resource path must start with "/data/" and be followed
> by at least one segment.  ({+restconf}/data is the path of the
> datastore resource, which is a different resource type.)
>
>        key-value = string      ;; note 1
>
> Of course, this is omitting the constraints about percent-encoding
> reserved characters and comma.
>
>    Note 1: The syntax for "api-identifier" and "key-value" MUST conform
>    to the JSON identifier encoding rules in Section 4 of
>    [I-D.ietf-netmod-yang-json].
>
> Is this note actually correct?
>
> 3.6.  Operation Resource
>
>    For example, if "module-A" defined a "reset" rpc operation, then
>    invoking the operation from "module-A" would be requested as follows:
>
> It seems like 'from "module-A"' is redundant in this context; we've
> already stated that the operation is in module-A.
>
>    All operation resources representing RPC operations supported by the
>    server MUST be identified in the {+restconf}/operations subtree
>    defined in Section 3.3.2.  Operation resources representing YANG
>    actions are not identified in this subtree since they are invoked
>    using a URI within the {+restconf}/data subtree.
>
> Isn't this paragraph redundant given the discussion at the beginning
> of the section?
>
> 3.6.2.  Encoding Operation Resource Output Parameters
>
>    The request URI is not returned in the response.  This URI might have
>    context information required to associate the output to the specific
>    "rpc" or "action" statement used in the request.
>
> Doesn't HTTP always allow the client to associate the response with
> the request that generated it?  If so, this paragraph is not really
> correct, as a returned request URI will not be "required" for the
> client to perform the association.  Perhaps what is meant is
> "knowledge of the request URI is needed to associate the output to the
> specific "rpc" or "action" statement referenced in the request".
>
> 3.8.  Event Stream Resource
>
>    The available streams can be retrieved from the stream list, which
>    specifies the syntax and semantics of a stream resource.
>
> Shouldn't that be "... the syntax and semantics of the stream resources"?
>
> 3.9.  Errors YANG Data Template
>
>    An "errors" YANG data template models a collection of error
>    information [...]
>
> Presumably, 'The "errors" YANG data template ...'.
>
> 4.  Operations
>
>    The following table shows how the RESTCONF operations relate to
>    NETCONF protocol operations and edit operations, which are identified
>    with the NETCONF "nc:operation" attribute.
>
> For people who don't know NETCONF, it would be clearer to say
> '... NETCONF protocol operations, and for the NETCONF edit operations,
> the "nc:operation" attribute.'
>
>    In particular, RESTCONF is compatible with the NETCONF
>    Access Control Model (NACM) [RFC6536], as there is a specific mapping
>    between RESTCONF and NETCONF operations, defined in Section 4.
>
> Since this text is contains in Section 4, you could omit "defined in
> Section 4".
>
>    Implementation of all methods (except PATCH) are defined in
>    [RFC7231].  This section defines the RESTCONF protocol usage for each
>    HTTP method.
>
> Why no RFC reference for the definition of PATCH?
>
> 4.2.  HEAD
>
>    The HEAD method is sent by the client to retrieve just the headers
>    that would be returned for the comparable GET method, without the
>    response message-body.  It is supported for all resource types,
>    except operation resources.
>
> It seems a lot safer (and future-proof) to say "It is supported by all
> resources that support GET."
>
> Also, it might be helpful to expand the first sentence, "... just the
> headers (which contain the metadata for a resource) ...".
>
> 4.3.  GET
>
>    The request MUST contain a request URI that contains at least the
>    entry point.
>
> Uses of the term "entry point" are scattered through the document but
> not listed in 1.1.5.
>
> I assume that it is implicit how a JSON GET should return multiple
> values.  It might help the reader to include an example of a GET that
> returns multiple nodes (using JSON, of course).
>
> BTW, what ETag and timestamp is returned by a GET whose URI identifies
> more than one value?
>
> 4.5.  PUT
>
>    If the target resource represents a YANG list instance, then the PUT
>    method MUST NOT change any key leaf values in the message-body
>    representation.
>
> Shouldn't this be "... any key leaf values in the instance."?
>
> 4.6.1.  Plain Patch
>
>    Please see
>    [I-D.ietf-netconf-yang-patch] for an alternate media-type supporting
>    the ability to delete child resources.  The YANG Patch Media Type
>    allows multiple sub-operations (e.g., merge, delete) within a single
>    PATCH operation.
>
> It seems these two sentences would be clearer if they were combined:
>
>    Please see [I-D.ietf-netconf-yang-patch] for an alternate
>    media-type that supports the deleting child resources and
>    specifying multiple sub-operations (e.g., merge, delete) within a
>    single PATCH operation.
>
> --
>
>    If the target resource represents a YANG list instance, then the
>    PATCH method MUST NOT change any key leaf values in the message-body
>    representation.
>
> Shouldn't that be "... any key leaf values in the instance"?
>
> Section 4.6.1 needs to specify that the plain patch operation never
> returns a response message-body.
>
> 4.7.  DELETE
>
>    To delete a resource such as the "album" resource, the client might
>    send:
>
> This would be clearer if it was
>
>    To delete the "album" resource with the key "Wasting Light", the client
>    might send:
>
> 4.8.2.  The "depth" Query Parameter
>
>    The "depth" parameter is used to specify the number of nest levels
>    returned in a response for a GET method.
>
> This would be better as 'Data nodes with a depth value exceeding the
> "depth" parameter are not returned in a response for a GET method.'
>
>    The first nest-level consists of the requested data node itself.
>
> It seems that this would be more clear as "The requested data node
> itself has depth value of 1."
>
>    If the "fields" parameter (Section 4.8.3) is used to select
>    descendant data nodes, these nodes all have a depth value of 1.
>
> You want to augment this as:
>
>    If the "fields" parameter (Section 4.8.3) is used to select
>    descendant data nodes, these nodes and all their ancestors have a
>    depth value of 1.
>
> The following text could be clarified by adding parentheses around
> this sentence:
>
>    (This has the effect of including the nodes specified by the
>    fields, even if the "depth" value is less than the actual depth
>    level of the specified fields.)
>
> --
>
>    Any child nodes which are contained within a parent node have a
>    depth value that is 1 greater than its parent.
>
> Probably better as "Any other child node has a depth value that is ...".
>
>    By default, the server will include all sub-resources within a
>    retrieved resource, which have the same resource type as the
>    requested resource.  The exception is the datastore resource.  If
>    this resource type is retrieved then by default the datastore and all
>    child data resources are returned.
>
> This specification requires that "resource type" be well-defined.
>
> 4.8.3.  The "fields" Query Parameter
>
> There should be a note that using "fields" does not select out a set
> of nodes whose values are returned as a *set* of values, it returns a
> *single* value, which is the value of the target data node, pruned by
> the removal of all nodes that are not ancestors of or descendants of
> one of the nodes specified in the "fields" parameter.  This is
> particularly important when considering the interaction of "fields"
> and "depth", and also is significant when the response representation
> is XML.
>
> 4.8.4.  The "filter" Query Parameter
>
>    This parameter is only allowed for GET methods on a text/event-stream
>    data resource.
>
> This is probably better put as "... on an event stream resource".
>
> Similarly in section 4.8.7.
>
> 4.8.7.  The "start-time" Query Parameter
>
>    If this query parameter is supported by the server, then the "replay"
>    query parameter URI MUST be listed in the "capability" leaf-list in
>    Section 9.3.  The "stop-time" query parameter MUST also be supported
>    by the server.
>
> For correctness, I think you need to join the two sentences:
> '... leaf-list in Section 9.3, and the "stop-time" query parameter
> MUST ...'.
>
> Similarly in section 4.8.8.
>
> 4.8.9.  The "with-defaults" Query Parameter
>
>    If the "with-defaults" parameter is set to "report-all-tagged" then
>    the server MUST adhere to the defaults reporting behavior defined in
>    Section 3.4 of [RFC6243].
>
> This needs a note that section 5.3 provides additional information
> about how default values are marked in responses when "with-defaults"
> is "report-all-tagged".
>
> 5.2.  Message Encoding
>
>    JSON encoding rules are defined in
>    [I-D.ietf-netmod-yang-json].  JSON encoding of metadata is defined in
>    [I-D.ietf-netmod-yang-metadata].
>
> There needs to be some sort of juncture between these two sentences.
> Does I-D.ietf-netmod-yang-json apply to metadata as well?  If so, the
> second sentence should start "Additional JSON encoding rules for
> metadata are ...".  If not, the subject of the first sentence should
> be modified to show that metadata is excluded.  ("JSON encoding rules
> for data are ..."?)
>
>    Response output content
>    encoding format is identified with the Accept header in the request.
>
> This should be
>
>    The response output content encoding formats that the client will
>    accept are identified with the Accept header in the request.
>
> --
>
>    File extensions encoded
>    in the request are not used to identify format encoding.
>
> I don't know of any place where a file extension can be encoded in the
> request.  But I get the unpleasant feeling that some server in the
> wild has been seen with this behavior and this warning is needed!
>
> 5.3.  RESTCONF Metadata
>
>    With the XML encoding, the metadata is encoded as attributes in XML.
>
> There should be some reference here as to how it should be done.
> Presumably this is a reference to RFC 6243.
>
> 5.3.2.  JSON MetaData Encoding Example
>
>    [...] so the YANG module name has to be assigned instead of derived
>    from the YANG module name.
>
> I don't think this is can be correct; one use of "YANG module name" is
> probably intended to be something else.
>
> "MetaData" should be "Metadata".
>
> 6.3.1.  NETCONF Event Stream
>
>    The server SHOULD support the "NETCONF" notification stream defined
>    in [RFC5277].
>
> It might help to note that the reference is to section 3.2.3 of RFC
> 5277.
>
> Is "notification stream" the same as "event stream"?  It seems like
> the draft should use one term or the other consistently.
>
> There is a lot of information about query parameters here, but it
> seems that it duplicates the discussion of query parameters elsewhere
> in the draft.  Could it be abbreviated?
>
> 6.4.  Receiving Event Notifications
>
>    The structure of the event data is based on the "notification"
>    element definition in Section 4 of [RFC5277].  It MUST conform to the
>    schema for the "notification" element in Section 4 of [RFC5277],
>    except the XML namespace for this element is defined as:
>
>    urn:ietf:params:xml:ns:yang:ietf-restconf
>
> "this element" is somewhat ambiguous; probably better as "the event
> data element".
>
>    RESTCONF servers that do send the
>    "id" field MUST still support the "startTime" query parameter as the
>    preferred means for a client to specify where to restart the event
>    stream.
>
> It seems "startTime" should be "start-time".
>
> But what is the significance of "MUST" here?  Implementing
> "start-time" is always optional (section 6.3.1).  Perhaps it would
> work to say
>
>     RESTCONF servers that send the "id" field SHOULD support the
>     "start-time" query parameter, as "start-time" is the preferred
>     means for specifying where to restart fetching the event stream.
>
> 7.  Error Reporting
>
>    The  element returned in NETCONF error
>    responses contains some useful information.
>
> I got confused by this sentence.  IIRC, this section is about error
> responses generally, not just error responses for RPC operations.  It
> seems the problem is that *all* Netconf operations are considered
> RPCs, so  covers all Netconf errors.  I think this could be
> made less confusing by combining this sentence with the following one
> as:
>
>    The error information that NETCONF error responses contain in the
>     element is adapted for use in RESTCONF, and an 
>    data tree information is returned for "4xx" and "5xx" class of
>    status codes.
>
> --
>
>    [...] a mapping between the NETCONF  value and the HTTP
> status
>    code is needed.
>
> Better to say "a mapping from the ... to the HTTP status code is
> needed." since the reverse mapping is not unique.
>
>    The semantics and syntax for RESTCONF error messages are defined with
>    the "yang-errors" YANG data template extension, found in Section 8.
>
> What is a "YANG data template extension"?  It probably means "YANG
> data template extension statement", but I think it could be reduced to
> 'the "errors" YANG data template'.  (Of course, see my comments about
> "YANG data template" at the beginning.)
>
> 7.1.  Error Response Message
>
>    The Content-Type of this response
>    message MUST be a subtype of application/yang-data (see example
>    below).
>
> This isn't the meaning of "subtype", which seems to be restricted (RFC
> 6838) to mean the part of the media type after "/".  This should work,
> though:
>
>    The Content-Type of this response message MUST be
>    application/yang-data, plus optionally a structured syntax name
>    suffix.
>
> "structured syntax name suffix" is defined in RFC 6838 section 4.2.8.
>
>    The client SHOULD specify the desired encoding for error messages by
>    specifying the appropriate media-type in the Accept header.  If no
>    error media is specified, [...]
>
> The client will specify the desired encoding for all responses, which
> perforce applies to error messages as well.  This can probably be
> reduced to:
>
>    The client SHOULD specify the desired encoding(s) for response
>    messages by specifying the appropriate media-type(s) in the Accept
>    header.  If the client did not specify an Accept header, [...]
>
> --
>
>    No response message-body content is expected by the
>    client in this example.
>
> Well, no content is expected on success, but the client was prepared
> for failure by providing an Accept.  Better say
>
>    There would be no response message-body content if this operation
>    was successful.
>
> The indentation of the DELETE example request and its response are
> different, which should probably be fixed.
>
> 8.  RESTCONF module
>
>         Note that the YANG definitions within this module do not
>         represent configuration data of any kind.
>
> Are there kinds of configuration data?  Seems like it would be better
> to say "... are never configuration data."
>
> And indeed, we could add 'config "false";' to the top-level objects to
> specify that directly in Yang.
>
>      ...
>
>      extension yang-data {
>       argument name {
>
> Is there a reason that the substatements of this extension statement
> are indented only 1 space?
>
>         yin-element true;
>       }
>       description
>         "This extension is used to specify a YANG data template which
>          represents conceptual data defined in YANG. It is
>          intended to describe hierarchical data independent of
>          protocol context or specific message encoding format.
>          Data definition statements within this extension specify
>          the generic syntax for the specific YANG data template.
>
> "this extension" is ambiguous, since it seems to me that it might be
> referring to the immediately preceding extension-statement.  I think
> the last sentence would be clearer as
>
>          Data definition statements within a yang-data extension
>          statement specify the generic syntax for the specific YANG
>          data template, whose name is the argument of the yang-data
>          extension statement.
>
> --
>
>          This extension is ignored unless it appears as a top-level
>          statement. It SHOULD contain data definition statements
>          that result in exactly one container data node definition.
>
> It seems like you can assure that the extension will never be used in
> an improper place, since only this document will use it.  Perhaps
>
>          The yang-data extension MUST only be a top-level statement of
>          a module.  It MUST contain only one schema node, which is a
>          container.
>
> --
>
>          This allows compliant translation to an XML instance
>          document for each YANG data template.
>
> This needs to specify the source of the name of the top-level XML
> element:
>
>          Instances of a YANG data template can thus be translated into
>          XML instances, whose top-level element corresponds to the
>          top-level container.
>
> --
>
>          The following data-def-stmt sub-statements have special
>          meaning when used within a yang-data-resource extension
>          statement.
>          - The list-stmt is not required to have a key-stmt defined.
>          - The if-feature-stmt is ignored if present.
>          - The config-stmt is ignored if present.
>          - The available identity values for any 'identityref'
>            leaf or leaf-list nodes is limited to the module
>            containing this extension statement, and the modules
>            imported into that module.
>
> It seems like poor practice to have the extension be described as
> changing the semantics of Yang.  Better would be to turn these into
> constraints, so that the valid contents of yang-data are a subset of
> Yang, but that subset has the same semantics as Yang prescribes:
>
>          - The if-feature-stmt must not be present.
>          - If the config-stmt is present, its value must be 'false'.
>          - The available identity values for any 'identityref'
>            leaf or leaf-list nodes is limited to the module
>            containing this extension statement, and the modules
>            imported into that module. [unchanged!]
>
> The item "The list-stmt is not required to have a key-stmt defined."
> is redundant, since everything inside yang-data is not configuration
> data, and non-configuration lists need not have keys.
>
> This section contains the following lines which name media types which
> do not exist.  Presumably this is a simple oversight and the correct
> types are known.
>
>           application/yang-api resource type.";
>
>             application/yang-api resource type.";
>
>              "Container representing the application/yang-datastore
>
>               (application/yang-operation),
>
> 9.  RESTCONF Monitoring
>
>    The "ietf-restconf-monitoring" module provides information about the
>    RESTCONF protocol capabilities and event notification streams
>    available from the server.  A RESTCONF server MUST implement the "/
>    restconf-state/capabilities" container in this module.
>
> Note that there is a line break in an incorrect place at the end of
> the third line.  Presumably it is due to an extraneous space in the
> XML2RFC file.
>
> It seems like the second sentence would be more informative as "A
> RESTCONF server MUST implement the ietf-restconf-monitoring module."
> Since restconf-state/capabilities is mandatory within the module, its
> existence need not be stated here.
>
>    YANG Tree Diagram for "ietf-restconf-monitoring" module:
>
> Shouldn't that be "YANG tree diagram ..."?
>
> The nodes 'description' and 'replay-support' are shown as optional in
> the tree diagram:
>
>    +--ro restconf-state
>       +--ro streams
>          +--ro stream* [name]
>             +--ro description?                string
>             +--ro replay-support?             boolean
>             +--ro replay-log-creation-time?   yang:date-and-time
>
> but there is no 'mandatory "false";' for those leafs in the module
> definition in section 9.3:
>
>            leaf description {
>              type string;
>              description "Description of stream content";
>              reference
>                "RFC 5277, Section 3.4,  element.";
>            }
>
>            leaf replay-support {
>              type boolean;
>              description
>                "Indicates if replay buffer supported for this stream.
>                 If 'true', then the server MUST support the 'start-time'
>                 and 'stop-time' query parameters for this stream.";
>              reference
>                "RFC 5277, Section 3.4,  element.";
>            }
>
> And the description should say that if replay-support is missing, its
> assumed value is false[?].  Or should a 'default' statement be
> employed?
>
> 9.1.2.  The "defaults" Protocol Capability URI
>
> This section is awkwardly phrased.  Perhaps:
>
>    This URI identifies the "basic-mode" defaults handling mode that is
>    used by the server for processing default leafs in requests for
>    data resources.  This protocol capability URI MUST be supported by
>    the server, and MUST be listed in the "capability" leaf-list in
>    Section 9.3.
>
>       +----------+--------------------------------------------------+
>       | Name     | URI                                              |
>       +----------+--------------------------------------------------+
>       | defaults | urn:ietf:params:restconf:capability:defaults:1.0 |
>       +----------+--------------------------------------------------+
>
>                      RESTCONF defaults capability URI
>
>    This URI MUST have attached a query a parameter named "basic-mode"
>    with one of the values listed below:
>
>    +------------------+------------------------------------------------+
>    | Value            | Description                                    |
>    +------------------+------------------------------------------------+
>    | report-all       | No data nodes are considered default           |
>    | trim             | Values set to the YANG default-stmt value are  |
>    |                  | default                                        |
>    | explicit         | Values set by the client are never considered  |
>    |                  | default                                        |
>    +------------------+------------------------------------------------+
>
>    The "basic-mode" behavior of the server is as specified for this
>    value in "With-Defaults Capability for NETCONF" [RFC6243]:
>
>    If the "basic-mode" is set to "report-all" then the server MUST
>    adhere to the defaults handling behavior defined in Section 2.1 of
>    [RFC6243].
>    [...]
>
> 9.2.  restconf-state/streams
>
>    This optional container provides access to the event notification
>    streams supported by the server.  The server MAY omit this container
>    if no event notification streams are supported.
>
> The second sentence is redundant, given that "streams" is a
> non-presence container, but it seems reasonable to warn the
> implementer here.
>
> 10.1.  modules-state
>
>    This mandatory container holds the identifiers for the YANG data
>    model modules supported by the server.
>
> This isn't how I'd phrase it.  I would say that modules-state/module
> holds the identifiers.  Perhaps omit this section and number 10.1.1 as
> "10.1"?
>
> 10.1.1.  modules-state/module
>
> If I understand correctly, the resource tree under {+restconf} is
> described by the ietf-restconf module.  All data resources not defined
> by ietf-restconf are descendants of {+restconf}/data, including the
> mandatory ietf-restconf-monitoring module.  But is ietf-restconf
> listed in
> {+restconf}/data/ietf-restconf-monitoring:modules-state/module?  I can
> see that this could be argued either way.
>
> 12.  Security Considerations
>
>    The "ietf-restconf-monitoring" YANG module defined in this memo is
>    designed to be accessed via the NETCONF protocol [RFC6241].  The
>    lowest NETCONF layer is the secure transport layer, and the
>    mandatory-to-implement secure transport is Secure Shell (SSH)
>    [RFC6242].  The NETCONF access control model [RFC6536] provides the
>    means to restrict access for particular NETCONF users to a pre-
>    configured subset of all available NETCONF protocol operations and
>    content.
>
> This reads oddly.  "ietf-restconf-monitoring" is designed to be
> accessed via the RESTCONF protocol.  However, RESTCONF does use the
> NETCONF access control model.  OTOH, this paragraph really isn't about
> ietf-restconf-monitoring, it's very general.  It seems to me that you
> want (and I may have the details wrong):
>
>    The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement
>    secure transport is TLS [RFC5246].  The RESTCONF protocol uses the
>    NETCONF access control model [RFC6536], which provides the means to
>    restrict access for particular RESTCONF users to a preconfigured
>    subset of all available RESTCONF protocol operations and content.
>
>    This section provides security considerations for the resources
>    defined by the RESTCONF protocol.  Security considerations for
>    HTTPS are defined in [RFC7230].  RESTCONF does not specify which
>    YANG modules a server needs to support, other than the
>    "ietf-restconf-monitoring" module.  Security considerations for the
>    other modules manipulated by RESTCONF can be found in the documents
>    defining those YANG modules.
>
> 14.1.  Normative References
>
> This draft has the longest normative references list I've ever seen!
>
> 14.2.  Informative References
>
>    [rest-dissertation]
>               Fielding, R., "Architectural Styles and the Design of
>               Network-based Software Architectures", 2000.
>
> Surely there is additional bibliographic information available for
> this!
>
> Appendix C.  Example YANG Module
>
>    +---x play
>       +--ro input
>          +--ro playlist       string
>          +--ro song-number    uint32
>
> The "x" indicator is not listed in section 1.1.7.  Is it "standard"
> for Yang tree diagrams?
>
> The "+---x" before "play" should be "+--x".  This will also fix the
> indenting problem.
>
> C.1.  example-jukebox YANG Module
>
>       ...
>       contact "support at example.com";
>
> Comparing with the examples of the contact statement in
> draft-ietf-netmod-rfc6020bis-14, it seems that this should be
> "support@example.com".
>
> Appendix D.  RESTCONF Message Examples
>
>    The examples within this document use the normative YANG module
>    defined in Section 8 and the non-normative example YANG module
>    defined in Appendix C.1.
>
> This would flow better (for me) if it included the module names:
>
>    The examples within this document use the normative YANG module
>    "ietf-restconf" defined in Section 8 and the non-normative example
>    YANG module "example-jukebox" defined in Appendix C.1.
>
> D.1.1.  Retrieve the Top-level API Resource
>
>       HTTP/1.1 200 OK
>       Date: Mon, 23 Apr 2012 17:01:00 GMT
>       Server: example-server
>       Content-Type: application/yang-data+json
>
>       {
>         "ietf-restconf:restconf": {
>           "data" : {},
>           "operations" : {},
>           "yang-library-version" : "2016-04-09"
>         }
>       }
>
>    The server will return the same response either way, which might be
>    as follows :
>
> It's not really the "same response".  "conceptual data" seems better.
>
> D.2.2.  Detect Resource Entity Tag Change
>
>    In this example, the server just supports the datastore last-changed
>    timestamp.  The client has previously retrieved the "Last-Modified"
>    header and has some value cached to provide in the following request
>    to patch an "album" list entry with key value "Wasting Light".  Only
>    the "genre" field is being updated.
>
> IIRC, the "value cached" is the URI
>
> /restconf/data/example-jukebox:jukebox/library/artist=Foo%20Fighters/album=Wasting%20Light
> for the album.  It seems this could be clearer as
>
>    After the previous request, the client has cached the
>    "Last-Modified" header and the Location header from the response to
>    provide the following request to patch the "album" list entry with
>    key value "Wasting Light".
>
> And then change the If-Unmodified-Since header in the request to use
> the value from the previous response, "Mon, 23 Apr 2012 17:03:00 GMT".
>
> D.2.3.  Edit a Datastore Resource
>
>    In this example, the client modifies two different data nodes by
>    sending a PATCH to the datastore resource:
>
> "different" might be redundant.
>
> It might be worth pointing out which nodes are being modified.  As far
> as I can see, the only modifiable nodes in the request data tree are
> the "year" nodes, but the "year" for "Wasting Light" in this update is
> the same as in its creation in D.2.1.  Should the request be modified?
>
> D.2.4.  Edit a Data Resource
>
>    In this example, the client modifies one data nodes by sending a
>    PATCH to the data resource (URI wrapped for display purposes only):
>
>    PATCH /restconf/data/example-jukebox:jukebox/library/
>       artist=Nick%20Cave%20and%20the%Bad%20Seeds HTTP/1.1
>    Host: example.com
>    Content-Type: application/yang-data
>
>    
>      Nick Cave and the Bad Seeds
>      
>        The Good Son
>        1990
>      
>    
>
> Should be "one data node".
>
> The example isn't very clear to me:  Which data node(s) is the PATCH
> intended to modify?  Does "modify a data node" mean that one single
> leaf is being modified, or does it include modification of an entire
> subtree?  "the data resource" seems to be an "artist" node, but that
> node per se isn't being modified.
>
> I think it would help to write what changes the PATCH was intended to
> cause, and adjust the wording accordingly.
>
> D.3.2.  "depth" Parameter
>
>    To determine if 1 or more resource instances exist for a given target
>    resource, the value "1" is used.
>
> Usually, this "1" would be spelled out as "one".
>
> The following two sections probably should have short text identifying
> what they illustrate.  E.g.,
>
> D.3.7.  "start-time" Parameter
>
>    The following URI shows an example of a start-time specification:
>
>    // start-time = 2014-10-25T10:02:00Z
>    GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z
>
> D.3.8.  "stop-time" Parameter
>
>    The following URI shows an example of a stop-time specification:
>
>    // stop-time = 2014-10-25T12:31:00Z
>    GET /mystreams/NETCONF?stop-time=2014-10-25T12%3A31%3A00Z
>
> This example is invalid, since it doesn't contain a start-time.
> (section 4.8.8) Perhaps:
>
>    The following URI shows an example of a stop-time specification
>    (lines wrapped for display purposes only):
>
>    // start-time = 2014-10-25T10:02:00Z
>    // stop-time = 2014-10-25T12:31:00Z
>    GET /streams/NETCONF?
>       start-time=2014-10-25T10%3A02%3A00Z&
>       stop-time=2014-10-25T12%3A31%3A00Z
>
> D.3.9.  "with-defaults" Parameter
>
>    The following YANG module is assumed for this example.
>
>      module example-interface {
>        prefix "exif";
>        namespace "urn:example.com:params:xml:ns:yang:example-interface";
>
>        container interfaces {
>          list interface {
>            key name;
>            leaf name { type string; }
>            leaf mtu { type uint32; }
>            leaf status {
>              config false;
>              type enumeration {
>                enum up;
>                enum down;
>                enum testing;
>              }
>            }
>          }
>        }
>      }
>
> As far as I can tell, module "example-interface" isn't used in this
> section.  "example-interface" seems to be an abbreviated version of
> module "example" in section A.1 of RFC 6243, but with the semantic
> difference that "example-interface" omits the default statement that
> drives the examples in this section.  It seems that you want to drop
> "example-interface" entirely and start the section with:
>
>    Assume the server implements the module "example" defined in
>    Appendix A.1 of [RFC6243].  Assume the server's datastore is as
>    defined in Appendix A.2 of [RFC6243].
>
> ----------------------------------------------------------------------
> Indentation of HTTP examples
>
> 1.5.  RESTCONF Extensibility
>       GET /.well-known/host-meta HTTP/1.1
>       HTTP/1.1 200 OK
> 3.1.  Root Resource Discovery
>       GET /.well-known/host-meta HTTP/1.1
>       HTTP/1.1 200 OK
>       GET /.well-known/host-meta HTTP/1.1
>       HTTP/1.1 200 OK
>       GET /top/restconf/operations  HTTP/1.1
>       HTTP/1.1 200 OK
> 3.3.1.  {+restconf}/data
>    GET /restconf/data/example-jukebox:jukebox/library
>    HTTP/1.1 200 OK
> 3.3.3.  {+restconf}/yang-library-version
>    GET /restconf/yang-library-version  HTTP/1.1
>    HTTP/1.1 200 OK
> 3.6.  Operation Resource
>    POST /restconf/operations/module-A:reset HTTP/1.1
>    POST /restconf/data/module-A:interfaces/reset-all HTTP/1.1
> 3.6.1.  Encoding Operation Resource Input Parameters
>    POST /restconf/operations/example-ops:reboot HTTP/1.1
>    HTTP/1.1 204 No Content
>       POST /restconf/operations/example-ops:reboot HTTP/1.1
>    POST /restconf/data/example-actions:interfaces/interface=eth0
>    HTTP/1.1 204 No Content
>       POST /restconf/data/example-actions:interfaces/interface=eth0
> 3.6.2.  Encoding Operation Resource Output Parameters
>    POST /restconf/operations/example-ops:get-reboot-info HTTP/1.1
>       HTTP/1.1 200 OK
>    HTTP/1.1 200 OK
>    POST /restconf/data/example-actions:interfaces/interface=eth0
>       HTTP/1.1 200 OK
> 3.6.3.  Encoding Operation Resource Errors
>    POST /restconf/operations/example-ops:reboot HTTP/1.1
>    HTTP/1.1 400 Bad Request
>       HTTP/1.1 400 Bad Request
> 3.7.  Schema Resource
>    GET /restconf/data/ietf-yang-library:modules-state/module=
>       HTTP/1.1 200 OK
>       HTTP/1.1
>       HTTP/1.1 200 OK
> 4.3.  GET
>    GET /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 200 OK
> 4.4.1.  Create Resource Mode
>       POST /restconf/data HTTP/1.1
>    HTTP/1.1 201 Created
> 4.4.2.  Invoke Operation Mode
>       POST /restconf/operations/example-jukebox:play   HTTP/1.1
>    HTTP/1.1 204 No Content
> 4.5.  PUT
>       PUT /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 204 No Content
>    PUT /restconf/data/example-jukebox:jukebox/
> 4.6.1.  Plain Patch
>    PATCH /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 204 No Content
> 4.7.  DELETE
>    DELETE /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 204 No Content
> 5.3.1.  XML MetaData Encoding Example
>    GET /restconf/data/interfaces/interface=eth1
>    HTTP/1.1 200 OK
> 5.3.2.  JSON MetaData Encoding Example
>    GET /restconf/data/interfaces/interface=eth1
>       HTTP/1.1 200 OK
> 6.2.  Event Streams
>    GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>    HTTP/1.1 200 OK
> 6.3.  Subscribing to Receive Notifications
>    GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>    HTTP/1.1 200 OK
>    GET /streams/NETCONF HTTP/1.1
>    GET /streams/NETCONF HTTP/1.1
> 7.1.  Error Response Message
>    DELETE /restconf/data/example-jukebox:jukebox/
>       HTTP/1.1 409 Conflict
>    POST /restconf/data/example-jukebox:jukebox HTTP/1.1
>    HTTP/1.1 409 Conflict
> 8.  RESTCONF module
>                  POST /restconf/operations/ietf-system:system-restart
>                  GET /restconf/operations
> D.1.1.  Retrieve the Top-level API Resource
>    GET /.well-known/host-meta HTTP/1.1
>    HTTP/1.1 200 OK
>    GET /restconf   HTTP/1.1
>       HTTP/1.1 200 OK
>    GET /restconf HTTP/1.1
>    HTTP/1.1 200 OK
> D.1.2.  Retrieve The Server Module Information
>    GET /restconf/data/ietf-yang-library:modules-state HTTP/1.1
>       HTTP/1.1 200 OK
> D.1.3.  Retrieve The Server Capability Information
>    GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>    HTTP/1.1 200 OK
> D.2.1.  Create New Data Resources
>       POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1
>    HTTP/1.1 201 Created
>    POST /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 201 Created
> D.2.2.  Detect Resource Entity Tag Change
>       PATCH /restconf/data/example-jukebox:jukebox/
>           HTTP/1.1
>    HTTP/1.1 412 Precondition Failed
> D.2.3.  Edit a Datastore Resource
>    PATCH /restconf/data HTTP/1.1
> D.2.4.  Edit a Data Resource
>    PATCH /restconf/data/example-jukebox:jukebox/library/
> D.3.1.  "content" Parameter
>    GET /restconf/data/example-events:events?content=all
>        HTTP/1.1
>       HTTP/1.1 200 OK
>    GET /restconf/data/example-events:events?content=config
>        HTTP/1.1
>       HTTP/1.1 200 OK
>    GET /restconf/data/example-events:events?content=nonconfig
>        HTTP/1.1
>       HTTP/1.1 200 OK
> D.3.2.  "depth" Parameter
>    GET /restconf/data/example-jukebox:jukebox?depth=unbounded
>        HTTP/1.1
>       HTTP/1.1 200 OK
>    GET /restconf/data/example-jukebox:jukebox?depth=1 HTTP/1.1
>       HTTP/1.1 200 OK
>    GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1
>       HTTP/1.1 200 OK
> D.3.3.  "fields" Parameter
>    GET /restconf/data?fields=ietf-yang-library:modules-state/
>       HTTP/1.1 200 OK
> D.3.4.  "insert" Parameter
>       POST /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 201 Created
> D.3.5.  "point" Parameter
>       POST /restconf/data/example-jukebox:jukebox/
>    HTTP/1.1 204 No Content
> D.3.6.  "filter" Parameter
>       GET /streams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault'
>       GET /streams/NETCONF?filter=%2Fevent%2Fseverity%3C%3D4
>       GET /streams/SNMP?filter=%2FlinkUp%7C%2FlinkDown
>       GET /streams/NETCONF?
>       GET /streams/critical-syslog?
>       GET /streams/NETCONF?
>       GET /streams/NETCONF?filter=(%2Fm1%3A*%20or%20%2Fm2%3A*)
> D.3.7.  "start-time" Parameter
>    GET /streams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z
> D.3.8.  "stop-time" Parameter
>    GET /mystreams/NETCONF?stop-time=2014-10-25T12%3A31%3A00Z
> D.3.9.  "with-defaults" Parameter
>    GET /restconf/data/example:interfaces/interface=eth1 HTTP/1.1
>       HTTP/1.1 200 OK
>    GET /restconf/data/example:interfaces/interface=eth1
>       HTTP/1.1 200 OK
> ----------------------------------------------------------------------
>
> Dale
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--001a113ab81a5dd5d90538fa4c56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

This will get added to the github i=
ssue list.

I am on vacation next week so edits wil=
l not be done for at least 2 weeks.


Andy


On Sun, Jul 31, 2016 at 5:19 PM, Dale R. Worley <worley=
@ariadne.com> wrote:
I am t=
he assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.=C2=A0 Please treat these comments just

like any other last call comments.



For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/=
wiki/GenArtfaq>.



Document: review-draft-ietf-netconf-restconf-15

Reviewer: Dale R. Worley

Review Date: 29 July 2016

IETF LC End Date: 3 August 2016

IESG Telechat date: "Not yet"



Summary:



This draft is basically ready for publication, but has nits that

should be fixed before publication.



* Technical nits



- In a few places, returned data can include URIs that are intended to

be usable by the client to retrieve information from the Restconf

server.=C2=A0 These places include the <location> element for accessi=
ng an

event stream, the Location header of POST responses, and the URLs for

retrieving schema resources (section 3.7).=C2=A0 The problem

is that implementing this assumes that the server knows a host

identifier (domain name or address) that the client can use to access

the server.=C2=A0 In general, given the ubiquity of NATs, the server

doesn't know this.



It seems to me that the two possible solutions are for the server to

be able to return a URI *relative reference* or for the server to use

as the host-part of the URL the value in the Host header of the

request (which perforce the server knows the client can use to access

the server).=C2=A0 Perhaps this is a known problem with a known solution
and so the draft doesn't bother to mention it.=C2=A0 Then again, perhap=
s in

practice the clients and the server are in region of the network

containing no internal NATS, and the problem does not arise.



But it seems to me that this could be a very general problem for

implementers and they should be instructed how to deal with it.=C2=A0 I

suspect that the authors know the intended resolution of this issue,

but it would help if the resolution was stated explicitly.



- Does XRD (RFC 6415) admit relative links as values of the href

attribute of the Link element?=C2=A0 Relative links are not usually

considered to be "URIs", but rather "URI-references" (R=
FC 3986 section

4.1), and RFC 6415 uses "URI" consistently, not "URI-referen=
ce".

Also, all examples in RFC 6415 show complete URIs.=C2=A0 If the href

attributes have to be full URIs, then the problem with host

identifiers described above also arises.



* General issues



- Might it be useful to consistently use a trailing-backslash

convention?=C2=A0 There are 17 places that state "lines wrapped for di=
splay

purposes only".=C2=A0 And there are places where lines are wrapped wit=
hout

this message, e.g., section 6.2.=C2=A0 It might be better for the reader to=


replace all of these messages with a single statement at the top:



=C2=A0 =C2=A0When a line ends with backslash as the last (non-whitespace)
=C2=A0 =C2=A0character, it is wrapped for display purposes.=C2=A0 It is to =
be

=C2=A0 =C2=A0considered to be joined to the next line by deleting the backs=
lash,

=C2=A0 =C2=A0the following line break, and the leading whitespace of the ne=
xt

=C2=A0 =C2=A0line.



- There is a general point regarding the interpretation of data resource
URLs.=C2=A0 Items in leaf-lists and lists that are not configuration data
need not have unique values/keys, and so a URL that selects nodes

within a leaf-list/list by providing a value may select multiple

target nodes.=C2=A0 The consequences of this do not seem to be explicitly
pointed out to the reader in any place.



In regard to retrieval requests (GET or HEAD), this is handled

correctly:=C2=A0 If the response is to be formatted in XML, the request

fails, because XML has no method to return multiple values.=C2=A0 If the
response is to be formatted in JSON, the request succeeds, because

JSON can return multiple values.=C2=A0 (As stated in section 4.3.)



All other requests methods modify the target resource(s), and

therefore cannot be directed to non-configuration data.=C2=A0 But

configuration data leaf-lists/lists must have unique values/keys, so a

URL that identifies modifiable resources must identify a unique

resource.=C2=A0 Most of the text conforms to this fact, but in section 4.7<=
br>
(regarding DELETE) is:



=C2=A0 =C2=A0If the target resource represents a YANG leaf-list or list, th=
en the

=C2=A0 =C2=A0DELETE method SHOULD NOT delete more than one such instance.


It seems to me that this situation cannot arise.



I don't think this issue requires much change to the text.=C2=A0 There =
is

the change to section 4.7 listed above, and it seems like it would be

useful to add a general warning in section 3.5.3:



=C2=A0 =C2=A0 A URI that specifies list/leaf-list values may contain a valu=
e

=C2=A0 =C2=A0 that identifies multiple data nodes.=C2=A0 Since duplicate va=
lues are

=C2=A0 =C2=A0 not permitted in configuration data, any such URI must identi=
fy

=C2=A0 =C2=A0 non-configuration data.=C2=A0 A request with such a URI is pr=
ocessed

=C2=A0 =C2=A0 according to the specifications of the request method; in

=C2=A0 =C2=A0 particular, since non-configuration data cannot be edited, a<=
br>
=C2=A0 =C2=A0 request with a method that changes data will necessarily be
=C2=A0 =C2=A0 rejected if the URI specifies multiple data nodes.



- The term "resource type" is used frequently but not defined.=C2=
=A0 It

seems that the set of all resources, i.e., valid URLs in the Restconf

interface, is divided into classes, each of which has a distinct

"resource type", and a distinct set of behaviors.=C2=A0 It would =
be very

useful to the reader to state this explicitly and list the resource

types.=C2=A0 The text almost does this implicitly, as the resource types
correspond fairly well to the subsections of section 3, though only

sections 3.1, 3.4, 3.5, 3.6, 3.7, and 3.8 correspond to resource

types.



See also the chart listing three resource types (Datastore, Data, and

Operation) in section 4.4.



There seem to be a few places where "resource media type" is used=
 to

mean the same thing as "resource type".=C2=A0 It seems like it sh=
ould be

replaced by "resource type".



- YANG data template



I think there is an important concept buried in the term "YANG data
template", but it isn't stated exactly anywhere, and it's not =
clear to

me precisely what it is.=C2=A0 There is an entry in section 1.1.5, "Te=
rms":



=C2=A0 =C2=A0o=C2=A0 YANG data template: a schema for modeling a conceptual=
 data

=C2=A0 =C2=A0 =C2=A0 structure in an encoding-independent manner.=C2=A0 It =
is defined with

=C2=A0 =C2=A0 =C2=A0 the "yang-data" extension, found in Section =
8.=C2=A0 It has a

=C2=A0 =C2=A0 =C2=A0 representation with the media-type "application/y=
ang-data" or

=C2=A0 =C2=A0 =C2=A0 "application/yang-data+json".



I can't figure out the exact relationship between "YANG data

template", "something defined with the yang-data extension",=
 "the

schema tree of a module", and "data that implicitly has

representations using XML and JSON".



The question of what is a "YANG data template" also interacts wit=
h the

question of what the purpose of the yang-data extension is.



I'm sure that the authors at least have an intuitive understanding of
how these concepts interrelate, but it doesn't seem to me that any of
this is laid out clearly for the naive reader.



I think this can be resolved by getting clear answers to these

questions:



-- Does the word "template" have a specific meaning?



The word "template" does not appear in

draft-ietf-netmod-rfc6020bis-14.=C2=A0 It doesn't seem to be equivalent=
 to

"schema tree", because that's defined as "The definition=
 hierarchy

specified within a module.", i.e., the entire tree defined by a

module.=C2=A0 Template seems to be equivalent to "the subtree rooted a=
t a

first-level schema node".



It may be that the phrase "YANG data template" would be better
replaced by some other phrase.



-- What is the significance of the phrase "a schema for modeling a

conceptual data structure in an encoding-independent manner"?



By assumption, all of the data in the implemented modules exists in an

encoding-independent manner, and the mere fact that it's accessible

via RESTCONF defines that it can be represented in XML and JSON.



-- What exactly does the yang-data extension statement do?



It seems to me that the draft doesn't need the extension.=C2=A0 For

example, in section 7.1 regarding error responses, the current text

is:



=C2=A0 =C2=A0When an error occurs for a request message on any resource typ=
e, and

=C2=A0 =C2=A0the status code that will be returned is in the "4xx"=
; range (except

=C2=A0 =C2=A0for status code "403 Forbidden"), then the server SH=
OULD send a

=C2=A0 =C2=A0response message-body containing the information described by =
the

=C2=A0 =C2=A0"yang-errors" YANG template definition within the &q=
uot;ietf-restconf"

=C2=A0 =C2=A0module, found in Section 8.



But it seems to me that it would suffice to say 'The response

message-body contains a representation of an instance of the "errors&q=
uot;

container in the "ietf-restconf" module find in Section 8 (using =
the

module name "ietf-restconf" and the namespace

"urn:ietf:params:xml:ns:yang:ietf-restconf").'



So what is the particular value of the yang-data extension and why is

it not needed for schema trees defined in ordinary implemented

modules?



-- While we're at it, where is the specification that all Yang data

has representations in XML and JSON?



Clearly there must be such a specification, as that's necessary for

Restconf to work at all, but I've overlooked it.



- There seem to be six statements in the draft that the fragment field

in RESTCONF resource URIs has no defined purpose, either for some set

of resources or for all resources.=C2=A0 (sections 3.4, 3.5, 3.6, 3.8, 5.1<=
br>
(twice)=C2=A0 But of course, the fragment identifier is never presented to<=
br>
the HTTP/HTTPS server for the resource -- see RFC 7230 section 5.1:



=C2=A0 =C2=A0The target URI excludes the reference's fragment component=
, if any,

=C2=A0 =C2=A0since fragment identifiers are reserved for client-side proces=
sing

=C2=A0 =C2=A0([RFC3986], Section 3.5).



It seems like a single statement of this fact would be sufficient, and

that section 5.1 is a natural place to put it, along with removing the

"fragment" field from the illustration of an HTTP request's
request-line:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 <OP> /<restconf>/<path>?<q=
uery>#<fragment>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^=C2=A0 =C2=A0 =C2=A0 =C2=A0^=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ^=C2=A0 =C2=A0 =C2=A0 =C2=A0^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0^

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 method=C2=A0 entry=C2=A0 resource=C2=A0 query=
=C2=A0 =C2=A0 fragment



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M=C2=A0 =C2=A0 =C2=A0 =C2=A0M=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 O=C2=A0 =C2=A0 =C2=A0 =C2=A0 O=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0I



However, the discussion of fragment identifiers in the media type

definitions is correct and proper.



- There seems to be a general inconsistency in indentation -- see the

end of the review for a list showing how each HTTP example is

indented.



- There should be only one space between the request URI and

"HTTP/1.1".=C2=A0 (RFC 7230 section 3.1.1)=C2=A0 This is done inc=
orrectly in:



=C2=A0 =C2=A0 3.1.=C2=A0 Root Resource Discovery

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 GET /top/restconf/operations=C2=A0 HTTP/=
1.1

=C2=A0 =C2=A0 3.3.1.=C2=A0 {+restconf}/data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0?content=3Dnonconfig=C2=A0 HTTP/1.=
1

=C2=A0 =C2=A0 3.3.3.=C2=A0 {+restconf}/yang-library-version

=C2=A0 =C2=A0 =C2=A0 =C2=A0GET /restconf/yang-library-version=C2=A0 HTTP/1.=
1

=C2=A0 =C2=A0 4.3.=C2=A0 GET

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 library/artist=3DFoo%20Fighters/album=3D=
Wasting%20Light=C2=A0 HTTP/1.1

=C2=A0 =C2=A0 4.4.2.=C2=A0 Invoke Operation Mode

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 POST /restconf/operations/example-jukebo=
x:play=C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 4.5.=C2=A0 PUT

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 library/artist=3DFoo%20Fig=
hters/album=3DWasting%20Light=C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library/artist=3DFoo%20Fighters/al=
bum=3DWasting%20Light=C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 D.1.1.=C2=A0 Retrieve the Top-level API Resource

=C2=A0 =C2=A0 =C2=A0 =C2=A0GET /restconf=C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 D.1.3.=C2=A0 Retrieve The Server Capability Information

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0capabilities=C2=A0 HTTP/1.1

=C2=A0 =C2=A0 D.2.1.=C2=A0 Create New Data Resources

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library/artist=3DFoo%20Fighters=C2=
=A0 HTTP/1.1

=C2=A0 =C2=A0 D.3.5.=C2=A0 "point" Parameter

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wasting%20Light%2Fsong%3DB=
ridge%20Burning=C2=A0 =C2=A0HTTP/1.1



- Percent-encoding



There are some details of percent-encoding that aren't fully

specified.=C2=A0 Percent-encoding is described in sections 3.5.3 and 5.1,
so I've consolidated the discussion here.



One is that the Yang string character set is Unicode, so to fully

specify how percent-encoding is done, we have to specify a character

representation to map Unicode characters into octets, after which

percent-encoding can be done.=C2=A0 These days the expected encoding for
Unicode is UTF-8, and percent-encoding using the UTF-8 representation

is described in the final paragraph of section 2.5 of RFC 3986.=C2=A0 This<=
br>
means that the item in section 3.5.3 should be changed from



=C2=A0 =C2=A0o=C2=A0 The key value is specified as a string, using the cano=
nical

=C2=A0 =C2=A0 =C2=A0 representation for the YANG data type.=C2=A0 Any reser=
ved characters

=C2=A0 =C2=A0 =C2=A0 MUST be percent-encoded, according to [RFC3986], secti=
on 2.1.



to



=C2=A0 =C2=A0o=C2=A0 The key value is specified as a string, using the cano=
nical

=C2=A0 =C2=A0 =C2=A0 representation for the YANG data type.=C2=A0 Any reser=
ved characters

=C2=A0 =C2=A0 =C2=A0 MUST be percent-encoded, according to [RFC3986], secti=
ons 2.1 and

=C2=A0 =C2=A0 =C2=A0 2.5.



and section 5.1 should be changed from



=C2=A0 =C2=A0Any reserved characters MUST be percent-encoded, according to<=
br>
=C2=A0 =C2=A0[RFC3986], sections 2.1 and 2.5.



- Must "," be percent-encoded when it appears in the key value fo=
r a

leaf-list node, given that a leaf-list path component cannot have more

than one key values?=C2=A0 See the comments for section 3.5.3.



- There are a number of questions regarding the ABNF in section

3.5.3.1 and precisely which URLs must conform to that syntax.=C2=A0 See the=


comments for that section.



- Is the ietf-restconf module listed in

{+restconf}/data/ietf-restconf-monitoring:modules-state/module?=C2=A0 I can=


see that this could be argued either way.=C2=A0 See the comments for

section 10.1.1.



- Generally, a colon in JSON is formatted with one space before and

one space after.=C2=A0 But these lines are formatted differently:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "@mtu": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-restconf:errors": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "error-type": &q=
uot;protocol",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "error-tag": &qu=
ot;lock-denied",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "error-message":=
 "Lock failed, lock already held"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-restconf:restconf": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-yang-library:modules-state": {<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "module-set-id": "5479120=
c17a619545ea6aff7aa19838b036ebbd7",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-yang-library:modules-state&qu=
ot;: {



* Nits



Table of Contents



=C2=A0 =C2=A0...

=C2=A0 =C2=A08.=C2=A0 RESTCONF module . . . . . . . . . . . . . . . . . . .=
 . . . .=C2=A0 66



This should be "RESTCONF Module".



1.=C2=A0 Introduction



=C2=A0 =C2=A0If a RESTCONF server is co-located with a NETCONF server, then=
 there

=C2=A0 =C2=A0are protocol interactions to be considered, as described in
=C2=A0 =C2=A0Section 1.4.



This is a bit vague, as it doesn't specify with *what* protocols there<=
br>
are interactions.=C2=A0 But this is obvious to most readers, as it's
concerned with interaction with the Netconf protocol.=C2=A0 But it's no=
t

obvious to readers who don't know Netconf, because the preceding text
only describes Netconf as a system of datastore semantics.=C2=A0 So I think=


this could be clarified by modifying this sentence:



=C2=A0 =C2=A0NETCONF defines configuration datastores and a set of Create,<=
br>
=C2=A0 =C2=A0Retrieve, Update, Delete (CRUD) operations that can be used to=
 access

=C2=A0 =C2=A0these datastores.



to



=C2=A0 =C2=A0NETCONF defines configuration datastores; a set of Create,

=C2=A0 =C2=A0Retrieve, Update, Delete (CRUD) operations that can be used to=
 access

=C2=A0 =C2=A0these datastores; and a protocol for invoking those operations=
.



and modifying the above sentence to



=C2=A0 =C2=A0If a RESTCONF server is co-located with a NETCONF server, then=
 there

=C2=A0 =C2=A0are protocol interactions with the NETCONF protocol, which are=
 described in

=C2=A0 =C2=A0Section 1.4.



and changing the first sentence/paragraph of 1.4 to



=C2=A0 =C2=A0RESTCONF can be implemented on a device that supports the NETC=
ONF protocol.



--



=C2=A0 =C2=A0Data-model specific RPC operations defined with the YANG "=
;rpc" or [...]



I think this should start "Data-model-specific", as all of that p=
hrase

is an adjective that modifies "RPC".=C2=A0 Similarly in the follo=
wing

sentence, and other places in the draft.



1.1.5.=C2=A0 Terms



The term "operation" is used in at least three senses:



- HTTP request methods (e.g., the title of section 4)

- abstract CRUD operations

- RPC operations, viz., from the Yang "rpc" and "action"=
; statements.



and also within



- edit operation: a RESTCONF operation on a data resource using

=C2=A0 either a POST, PUT, PATCH, or DELETE method.



You need to check that you have ways to specify each of these, and

that all uses of "operation" are unambiguous.=C2=A0 It might be u=
seful to

mention this ambiguity in the lexicon item for "operations".



=C2=A0 =C2=A0o=C2=A0 API resource: a resource that models the RESTCONF entr=
y point and

=C2=A0 =C2=A0 =C2=A0 the sub-resources to access YANG-defined content.=C2=
=A0 It is defined

=C2=A0 =C2=A0 =C2=A0 with the YANG data template named "yang-api"=
 in the

=C2=A0 =C2=A0 =C2=A0 "ietf-restconf" module.



This should probably start "the resource that ...", as there is o=
nly one.



=C2=A0 =C2=A0o=C2=A0 data resource: a resource that models a YANG data node=
.=C2=A0 It is

=C2=A0 =C2=A0 =C2=A0 defined with YANG data definition statements, and YANG=
 containers,

=C2=A0 =C2=A0 =C2=A0 leafs, leaf-list entries, list entries, anydata and an=
yxml nodes

=C2=A0 =C2=A0 =C2=A0 can be data resources.



It seems redundant to say "and YANG containers, leafs, leaf-list

entries, list entries, anydata and anyxml nodes can be data

resources.", because that is the whole list of YANG entities that can<=
br>
be data nodes.=C2=A0 Worse, if a new YANG data node type is added, this

list will have to be updated.=C2=A0 Would it be acceptable to delete the
second sentence?



=C2=A0 =C2=A0o=C2=A0 datastore resource: a resource that models a programma=
tic

=C2=A0 =C2=A0 =C2=A0 interface to NETCONF datastores.



This should probably start "the resource that ...", as there is o=
nly one.



I think "NETCONF datastores" should be "the NETCONF datastor=
e", since a

datastore resource must model exactly one NETCONF datastore.



=C2=A0 =C2=A0o=C2=A0 event stream resource: This resource represents an SSE=
 (Server-

=C2=A0 =C2=A0 =C2=A0 Sent Events) event stream.=C2=A0 The content consists =
of text using the

=C2=A0 =C2=A0 =C2=A0 media type "text/event-stream", as defined b=
y the SSE

=C2=A0 =C2=A0 =C2=A0 [W3C.REC-eventsource-20150203] specification.=C2=A0 Ea=
ch event

=C2=A0 =C2=A0 =C2=A0 represents one <notification> message generated =
by the server.=C2=A0 It

=C2=A0 =C2=A0 =C2=A0 contains a conceptual system or data-model specific ev=
ent that is

=C2=A0 =C2=A0 =C2=A0 delivered within an event notification stream.=C2=A0 A=
lso called a

=C2=A0 =C2=A0 =C2=A0 "stream resource".



What is a "<notification> message"?=C2=A0 Is <notificati=
on> a concept from the

NETCONF protocol?=C2=A0 It is not used elsewhere in the draft.



Also, an event does not represent a notification message, a

notification message represents an event.



The "It" in "It contains a conceptual system" seems amb=
iguous.=C2=A0 Do you

mean "Each message contains ..."?



Also, it seems that "system or data-model specific event" would b=
e

clearer as "system event or data-model-specific event", to make i=
t

clear that "system" is an adjective.



=C2=A0 =C2=A0o=C2=A0 patch: a generic PATCH request on the target datastore=
 or data

=C2=A0 =C2=A0 =C2=A0 resource.=C2=A0 The media type of the message-body con=
tent will

=C2=A0 =C2=A0 =C2=A0 identify the patch type in use.



Does the "generic" add meaning here, or can it be omitted without=


loss?



=C2=A0 =C2=A0o=C2=A0 plain patch: a specific PATCH request type, defined in=


=C2=A0 =C2=A0 =C2=A0 Section 4.6.1, that can be used for simple merge opera=
tions.=C2=A0 It

=C2=A0 =C2=A0 =C2=A0 has a representation with the media-type "applica=
tion/yang-data"

=C2=A0 =C2=A0 =C2=A0 or "application/yang-data+json".



I don't think that "PATCH request type" is defined.=C2=A0 Als=
o the use of

"representation" is odd.=C2=A0 Perhaps:



=C2=A0 =C2=A0o=C2=A0 plain patch: a specific PATCH request type, defined in=


=C2=A0 =C2=A0 =C2=A0 Section 4.6.1, that can be used for simple merge opera=
tions.=C2=A0 It

=C2=A0 =C2=A0 =C2=A0 is specified by a request Content-Type of "applic=
ation/yang-data"

=C2=A0 =C2=A0 =C2=A0 or "application/yang-data+json".



--



=C2=A0 =C2=A0o=C2=A0 RESTCONF capability: An optional RESTCONF protocol fea=
ture

=C2=A0 =C2=A0 =C2=A0 supported by the server, which is identified by an IAN=
A registered

=C2=A0 =C2=A0 =C2=A0 NETCONF Capability URI, and advertised with an entry i=
n the

=C2=A0 =C2=A0 =C2=A0 "capability" leaf-list in Section 9.3.



Probably should be "[...] leaf-list defined in Section 9.3.".



=C2=A0 =C2=A0o=C2=A0 RESTCONF client: a client which implements the RESTCON=
F protocol.

=C2=A0 =C2=A0 =C2=A0 Also called "client".



It seems to me that the "Also called ..." clauses (for "clie=
nt",

"server", and "stream resource") should be turned into =
stand-alone

entries, as otherwise it's difficult to find the definition of

"client", etc.



=C2=A0 =C2=A0o=C2=A0 schema resource: a resource that has a representation =
with the

=C2=A0 =C2=A0 =C2=A0 media type "application/yang".=C2=A0 The sch=
ema resource is used by the

=C2=A0 =C2=A0 =C2=A0 client to retrieve the YANG schema with the GET method=
.



Is the defining characteristic of a schema resource that it 'has a

representation with the media type "application/yang"'?=C2=A0=
 Or is its

defining characteristic the fact that "the client [can use it] to

retrieve the YANG schema"?=C2=A0 If the latter, I suggest reversing th=
e

two sentences:



=C2=A0 =C2=A0o=C2=A0 schema resource: a resource that can be used by the cl=
ient to

=C2=A0 =C2=A0 =C2=A0 retrieve a YANG schema.=C2=A0 It has a representation =
with the

=C2=A0 =C2=A0 =C2=A0 media type "application/yang".



--



1.2.=C2=A0 Subset of NETCONF Functionality



=C2=A0 =C2=A0The HTTP POST, PUT, PATCH, and DELETE methods are used to edit=
 data

=C2=A0 =C2=A0resources represented by YANG data models.=C2=A0 These basic e=
dit

=C2=A0 =C2=A0operations allow the running configuration to be altered in an=
 all-

=C2=A0 =C2=A0or-none fashion.



What is the meaning of "all-or-none" here?=C2=A0 Initially, I tho=
ugh it

meant that the actions were atomic, in that they either succeeded

completely or had no effect, but it might be referring to the fact

that RESTCONF cannot assemble a transaction from several elementary

editing operations.



=C2=A0 =C2=A0RESTCONF is not intended to replace NETCONF, but rather provid=
e an

=C2=A0 =C2=A0additional interface that follows Representational State Trans=
fer

=C2=A0 =C2=A0(REST) principles [rest-dissertation], and is compatible with =
a

=C2=A0 =C2=A0resource-oriented device abstraction.



Given the first sentence of section 1, the major goal of RESTCONF

seems to be to be HTTP-based, so it might be more accurate to say

"... to provide an HTTP interface that follows ...".



Could "compatible with a resource-oriented device abstraction" be=
 more

usefully expressed as "compatible with the NETCONF datastore model&quo=
t;?



=C2=A0 =C2=A0 =C2=A0 +-----------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
+-----------------+

=C2=A0 =C2=A0 =C2=A0 |=C2=A0 Web app=C2=A0 | <-------> |=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 +-----------+=C2=A0 =C2=A0HTTP=C2=A0 =C2=A0 | network =
device=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 +-----------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
|=C2=A0 =C2=A0+-----------+ |

=C2=A0 =C2=A0 =C2=A0 |=C2=A0 NMS app=C2=A0 | <-------> |=C2=A0 =C2=A0=
| datastore | |

=C2=A0 =C2=A0 =C2=A0 +-----------+=C2=A0 NETCONF=C2=A0 |=C2=A0 =C2=A0+-----=
------+ |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------+



The figure does not show that the "Web app" is using RESTCONF -- =
it's

an illustration of the use of RESTCONF that doesn't specify where

RESTCONF is used!=C2=A0 Perhaps change to "RESTCONF over HTTP"?


"NMS" is used nowhere else in the draft.=C2=A0 I assume it means =
"network

management system".=C2=A0 Perhaps all readers are expected to know tha=
t.

Otherwise, "NETCONF client" would be better.=C2=A0 (And can't=
 a network

management system use Restconf?)



1.3.=C2=A0 Data Model Driven API



=C2=A0 =C2=A0Using YANG, a client can predict all management resources, muc=
h like

=C2=A0 =C2=A0using URI Templates [RFC6570], but in a more holistic manner.<=
br>


Better,



=C2=A0 =C2=A0Knowing the YANG modules describing the server's data mode=
l, a

=C2=A0 =C2=A0client can derive all management resource URLs and the proper<=
br>
=C2=A0 =C2=A0structure of all RESTCONF requests and responses.



--



=C2=A0 =C2=A0RESTCONF provides the YANG module capability information suppo=
rted by

=C2=A0 =C2=A0the server, in case the client wants to use it.=C2=A0 The URIs=
 for data-

=C2=A0 =C2=A0model specific RPC operations and datastore content are predic=
table,

=C2=A0 =C2=A0based on the YANG module definitions.



I've folded the second sentence of this passage into the previous

edit.=C2=A0 It seems like the first sentence could be phrased more simply,<=
br>
"RESTCONF allows the client to retrieve the list of YANG modules

supported by the server."=C2=A0 Actually, I'm not sure that's =
correct; what

is "the YANG module capability information"?=C2=A0 The only use o=
f

"capability" in draft-ietf-netmod-rfc6020bis-14 is for the capabi=
lity

identifier URI urn:ietf:params:netconf:capability:yang-library:1.0,

which is mandatory to implement (since there is no other version

defined).



You might want to note here that the server might provide the

definitions of the modules that it supports.=C2=A0 E.g., "The server c=
an

optionally support retrieval of the YANG modules it supports; see

Section 3.7."



=C2=A0 =C2=A0The RESTCONF datastore editing model is simple and direct, sim=
ilar to

=C2=A0 =C2=A0the behavior of the :writable-running capability in NETCONF.=
=C2=A0 Each

=C2=A0 =C2=A0RESTCONF edit of a datastore resource is activated upon succes=
sful

=C2=A0 =C2=A0completion of the transaction.



I don't know the exact terminology that is used in this field, but I
think the final word would better be "edit".=C2=A0 The problem is=
 that

"transaction" is used in the database world to mean everything
starting with the first edit operation and ending with the commit to

permanent storage.=C2=A0 With that definition, the "completion of the<=
br>
transaction" happens only after the commit is finished.=C2=A0 But in t=
his

context, the commit is the same as "a datastore resource is

activated"!



1.4.=C2=A0 Coexistence with NETCONF



It seems to me that the section would more accurately be described as

"Datastore and transaction management".



=C2=A0 =C2=A0If the device supports :startup, the device MUST automatically=
 update

=C2=A0 =C2=A0the non-volatile "startup datastore", after the runn=
ing datastore has

=C2=A0 =C2=A0been updated as a consequence of a RESTCONF edit operation.


Is there a reason that there are double-quotes around "startup

datastore"?=C2=A0 I do not see that usage in RFC 6241.



1.5.=C2=A0 RESTCONF Extensibility



=C2=A0 =C2=A0This document defines version 1 of the RESTCONF protocol.=C2=
=A0 If a

=C2=A0 =C2=A0future version of this protocol is defined, then that document=
 will

=C2=A0 =C2=A0specify how the new version of RESTCONF is identified.=C2=A0 I=
t is

=C2=A0 =C2=A0expected that a different entry point {+restconf2} would be de=
fined.



The symbol "{+restconf2}" has no defined meaning.=C2=A0 I think y=
ou want

"It is expected that a different entry point will be used, which will<=
br>
be located using a different link relation (Section 3.1)."



=C2=A0 =C2=A0 =C2=A0 Response

=C2=A0 =C2=A0 =C2=A0 --------

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0 =C2=A0 Content-Type: application/xrd+xml

=C2=A0 =C2=A0 =C2=A0 Content-Length: nnn



=C2=A0 =C2=A0<XRD xmlns=3D'http://docs.oasis-open.or=
g/ns/xri/xrd-1.0'>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<Link rel=3D'restconf' href=3D'/r=
estconf'/>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<Link rel=3D'restconf2' href=3D'/=
restconf2'/>

=C2=A0 =C2=A0</XRD>



The response message-body isn't indented to the same margin as the

headers.



=C2=A0 =C2=A0Typically this extension mechanism is used to identify optiona=
l query

=C2=A0 =C2=A0parameters but it is not limited to that purpose.



Should this say "optional query parameters that are supported"?=
=C2=A0 Also,

could "Typically" be improved as "Currently"?



2.2.=C2=A0 HTTPS with X.509v3 Certificates



=C2=A0 =C2=A0The use the X.509v3 based certificates is consistent with NETC=
ONF

=C2=A0 =C2=A0over TLS [RFC7589].



There is a syntax error in the first few words of this sentence.



=C2=A0 =C2=A0The RESTCONF client MUST either use X.509 certificate path val=
idation

=C2=A0 =C2=A0[RFC5280] to verify the integrity of the RESTCONF server's=
 TLS

=C2=A0 =C2=A0certificate, or match the presented X.509 certificate with loc=
ally

=C2=A0 =C2=A0configured certificate fingerprints.



=C2=A0 =C2=A0The presented X.509 certificate MUST also be considered valid =
if it

=C2=A0 =C2=A0matches a locally configured certificate fingerprint.=C2=A0 If=
 X.509

=C2=A0 =C2=A0certificate path validation fails and the presented X.509 cert=
ificate

=C2=A0 =C2=A0does not match a locally configured certificate fingerprint, t=
he

=C2=A0 =C2=A0connection MUST be terminated as defined in [RFC5246].



The second sentence seems to be redundant with the second clause of

the first sentence.=C2=A0 (Or is it intended that the client MUST be

configurable with fingerprints?)=C2=A0 The last sentence seems to be

verbose; it should be possible to say "If the certificate cannot be
validated by either method, ...".



3.=C2=A0 Resources



=C2=A0 =C2=A0A resource has a representation associated with a media type
=C2=A0 =C2=A0identifier, as represented by the "Content-Type" hea=
der in the HTTP

=C2=A0 =C2=A0response message.



This seems awkward.=C2=A0 Perhaps:



=C2=A0 =C2=A0A resource has one or more representations, each associated wi=
th a

=C2=A0 =C2=A0different media type.=C2=A0 When a representation of a resourc=
e is sent

=C2=A0 =C2=A0in an HTTP response message, the associated media type is give=
n in

=C2=A0 =C2=A0the "Content-Type" header.



--



=C2=A0 =C2=A0All RESTCONF resource types are defined in this document excep=
t

=C2=A0 =C2=A0specific datastore contents, RPC operations, and event notific=
ations.



This depends on exactly what "resource type" means.=C2=A0 As disc=
ussed at

the beginning, that phrase seems to mean a small, finite number of

resource classes that are all defined in this document.=C2=A0 I think what<=
br>
this sentence is trying to get at is that the specific resources of a

particular server that are in each of the resource type classes is

determined by the set of modules the server implements.=C2=A0 But that

isn't what the sentence says (assuming I'm correct about what

"resource type" means).



=C2=A0 =C2=A0The syntax and semantics for these resource types are defined =
in YANG

=C2=A0 =C2=A0modules.



Perhaps "... are defined in the YANG modules that the server

implements.".



=C2=A0 =C2=A0The RESTCONF protocol does not include a data resource discove=
ry

=C2=A0 =C2=A0mechanism.=C2=A0 Instead, the definitions within the YANG modu=
les

=C2=A0 =C2=A0advertised by the server are used to construct a predictable
=C2=A0 =C2=A0operation or data resource identifier.



It seems like "predictable" is redundant given the use of "c=
onstruct".



3.1.=C2=A0 Root Resource Discovery



=C2=A0 =C2=A0After discovering the RESTCONF API root, the client MUST prepe=
nd it

=C2=A0 =C2=A0to any subsequent request to a RESTCONF resource.



It's not actually prepended to the *request*, it's the initial part=
 of

the path of the request URI:



=C2=A0 =C2=A0The RESTCONF API root is used as the initial part of the path =
of

=C2=A0 =C2=A0the request URI of any request to a RESTCONF resource.



Because of the resource discovery system, any given host:port can

support only one RESTCONF server.=C2=A0 This means that a particular host
is not expected to support an arbitrarily large number of RESTCONF

servers, as each server must use a different port.=C2=A0 I doubt this is a<=
br>
practical limitation for the intended usages, but it's probably worth
mentioning in the Introduction.



3.3.=C2=A0 API Resource



=C2=A0 =C2=A0+--rw restconf

=C2=A0 =C2=A0 =C2=A0 +--rw data

=C2=A0 =C2=A0 =C2=A0 +--rw operations

=C2=A0 =C2=A0 =C2=A0 +--ro yang-library-version



That seems to imply that the root resource has the name "restconf"=
; (or

perhaps that the last component of its name is "restconf").=C2=A0=
 I think

you could be more accurate (with some abuse of notation) by:



=C2=A0 =C2=A0+--rw {+restconf}

=C2=A0 =C2=A0 =C2=A0 +--rw data

=C2=A0 =C2=A0 =C2=A0 +--rw operations

=C2=A0 =C2=A0 =C2=A0 +--ro yang-library-version



Section 1.7 says 'Ellipsis ("...") stands for contents of sub=
trees

that are not shown.', but ellipsis is not exploited here to clarify

where in the tree additional nodes will be:



=C2=A0 =C2=A0+--rw {+restconf}

=C2=A0 =C2=A0 =C2=A0 +--rw data

=C2=A0 =C2=A0 =C2=A0 |=C2=A0 ...

=C2=A0 =C2=A0 =C2=A0 +--rw operations?

=C2=A0 =C2=A0 =C2=A0 |=C2=A0 ...

=C2=A0 =C2=A0 =C2=A0 +--ro yang-library-version



Section 3.3.2 states that "operations" is optional, so there shou=
ld be

a "?" after "operations".



=C2=A0 =C2=A0The "yang-api" YANG data template is defined with th=
e "yang-data"

=C2=A0 =C2=A0extension in the "ietf-restconf" module, found in Se=
ction 8.=C2=A0 It is

=C2=A0 =C2=A0used to specify the structure and syntax of the conceptual chi=
ld

=C2=A0 =C2=A0resources within the API resource.



I think this would be clearer if you said '... defined using the

"yang-data" extension', and "It specifies the structure =
and syntax

...".



3.4.=C2=A0 Datastore Resource



=C2=A0 =C2=A0The "{+restconf}/data" subtree represents the datast=
ore resource

=C2=A0 =C2=A0type, which is a collection of configuration data and state da=
ta

=C2=A0 =C2=A0nodes.



Shouldn't this be "... represents the datastore, which is ..."=
;?



=C2=A0 =C2=A0This resource type is an abstraction of the system's under=
lying

=C2=A0 =C2=A0datastore implementation.=C2=A0 It is used to simplify resourc=
e editing

=C2=A0 =C2=A0for the client.=C2=A0 The RESTCONF datastore resource is a con=
ceptual

=C2=A0 =C2=A0collection of all configuration and state data that is present=
 on the

=C2=A0 =C2=A0device.



The first sentence is extremely clear.=C2=A0 The second sentence is odd;
doesn't it mean "The client uses it to edit resources."?=C2=
=A0 The third

sentence seems to be a longer statement of the first sentence, given

what the datastore is.



=C2=A0 =C2=A0Configuration edit transaction management and configuration
=C2=A0 =C2=A0persistence are handled by the server and not controlled by th=
e

=C2=A0 =C2=A0client.=C2=A0 A datastore resource can be written directly wit=
h the POST

=C2=A0 =C2=A0and PATCH methods.=C2=A0 Each RESTCONF edit of a datastore res=
ource is

=C2=A0 =C2=A0saved to non-volatile storage by the server, if the server sup=
ports

=C2=A0 =C2=A0non-volatile storage of configuration data.



The second sentence makes sense in this context.=C2=A0 The first and third<=
br>
sentences are datastore management, which is discussed in section 1.4.



3.4.1.=C2=A0 Edit Collision Detection



=C2=A0 =C2=A0Two "edit collision detection" mechanisms are provid=
ed in RESTCONF,

=C2=A0 =C2=A0for datastore and data resources.



Why are there double-quotes around "edit collision detection"?


There seems to be a third mechanism:=C2=A0 if the datastore is locked, the<=
br>
request gets a 409 response (section 1.4).=C2=A0 Though maybe that's mo=
re

"collision prevention" than "collision detection".



3.4.1.1.=C2=A0 Timestamp



=C2=A0 =C2=A0If the RESTCONF server is colocated with a NETCONF server, the=
n the

=C2=A0 =C2=A0last-modified timestamp MUST represent the "running"=
 datastore.



"represent" isn't the right word here.=C2=A0 Perhaps "..=
. MUST be that of

...".=C2=A0 Of course, this fact is implicit in the Restconf definitio=
n,

because Restconf provides access only to the running datastore, but

it's worth warning the implementer explicitly.



3.4.1.2.=C2=A0 Entity tag



=C2=A0 =C2=A0A unique opaque string is maintained and the "ETag" =
([RFC7232],

=C2=A0 =C2=A0Section 2.3) header is returned in the response for a retrieva=
l

=C2=A0 =C2=A0request.=C2=A0 The "If-Match" header can be used in =
edit operation

=C2=A0 =C2=A0requests to cause the server to reject the request if the reso=
urce

=C2=A0 =C2=A0entity tag does not match the specified value.



It seems you want 2119 language here:



=C2=A0 =C2=A0The server MUST maintain a unique opaque entity-tag for the
=C2=A0 =C2=A0datastore resource and MUST return it in the "ETag" =
([RFC7232],

=C2=A0 =C2=A0Section 2.3) header in the response for a retrieval request.=
=C2=A0 The

=C2=A0 =C2=A0client MAY use an "If-Match" header in edit operatio=
n requests to

=C2=A0 =C2=A0cause the server to reject the request if the resource entity =
tag

=C2=A0 =C2=A0does not match the specified value.



An interesting point that you may want to warn the reader about is

that the entity-tag encodes not only the data in the resource but also

its representation; different representations (XML vs. JSON) must have

different entity-tags.=C2=A0 (RFC 7323 section 2.3)



=C2=A0 =C2=A0If the RESTCONF server is colocated with a NETCONF server, the=
n this

=C2=A0 =C2=A0entity tag MUST represent the "running" datastore.


"represent" isn't the right word here.=C2=A0 Perhaps "..=
. MUST be that of ...".



3.4.1.3.=C2=A0 Update Procedure



It seems like the substantial part of this section is "Changes to

configuration data resources affect the timestamp and entity tag to

... the datastore resource."=C2=A0 The rest of what it says is more fu=
lly

described in section 3.5.=C2=A0 It seems that the real point is to state
that changing any of the configuration resources changes the

timestamp/ETag of the datastore resource, which is more or less

understood, given that the datastore has a timestamp/ETag.=C2=A0 But it

seems that this could be more clearly said in 3.4.1:



=C2=A0 =C2=A0Two "edit collision detection" mechanisms are provid=
ed in RESTCONF

=C2=A0 =C2=A0for the datastore:=C2=A0 a timestamp and an ETag.=C2=A0 (These=
 may also be

=C2=A0 =C2=A0provided for data resources; see Section 3.5.)=C2=A0 Any chang=
e to

=C2=A0 =C2=A0configuration data resources updates the timestamp and entity =
tag

=C2=A0 =C2=A0of the datastore resource.



3.5.=C2=A0 Data Resource



=C2=A0 =C2=A0A configuration data resource can be altered by the client wit=
h some

=C2=A0 =C2=A0or all of the edit operations, depending on the target resourc=
e and

=C2=A0 =C2=A0the specific operation.=C2=A0 Refer to Section 4 for more deta=
ils on edit

=C2=A0 =C2=A0operations.



It seems like this paragraph is largely redundant.



3.5.3.=C2=A0 Encoding Data Resource Identifiers in the Request URI



=C2=A0 =C2=A0In YANG, data nodes are identified with an absolute XPath expr=
ession,

=C2=A0 =C2=A0defined in [XPath], starting from the document root to the tar=
get

=C2=A0 =C2=A0resource.=C2=A0 In RESTCONF, URI-encoded path expressions are =
used

=C2=A0 =C2=A0instead.



I think "are identified" should be "can be identified" =
-- relative

XPath is also allowed in Yang.



=C2=A0 =C2=A0If a node in the

=C2=A0 =C2=A0path is defined in another module than its parent node, then m=
odule

=C2=A0 =C2=A0name followed by a colon character (":") is prepende=
d to the node

=C2=A0 =C2=A0name in the resource identifier.



That should start "If a node in the path is defined in another module<=
br>
than its parent node, or its parent is the datastore, then module

...".



The following item appears in the list concerning list nodes:



=C2=A0 =C2=A0o=C2=A0 The key value is specified as a string, using the cano=
nical

=C2=A0 =C2=A0 =C2=A0 representation for the YANG data type.=C2=A0 Any reser=
ved characters

=C2=A0 =C2=A0 =C2=A0 MUST be percent-encoded, according to [RFC3986], secti=
on 2.1.



This fact also needs to be specified for leaf-list nodes, so either

this item should be duplicated into the list of items for leaf-list

nodes, or it should be pulled out as a top-level paragraph.



The reader needs to be warned that in the the character "," in a =
key

value must also be percent-encoded, despite that it is not considered

"reserved" in any definition of URL.



This leads to a technical nit:=C2=A0 Must "," be percent-encoded =
when it

appears in the key value for a leaf-list node, given that a leaf-list

path component cannot have more than one key values?=C2=A0 (Whether this is=


specified as true or false is not important, but the standard needs to

fix the requirement.)



=C2=A0 =C2=A0Resource URI values returned in Location headers for data reso=
urces

=C2=A0 =C2=A0MUST identify the module name as specified in

=C2=A0 =C2=A0[I-D.ietf-netmod-yang-json], even if there are no conflicting =
local

=C2=A0 =C2=A0names when the resource is created.=C2=A0 This ensures the cor=
rect

=C2=A0 =C2=A0resource will be identified even if the server loads a new mod=
ule

=C2=A0 =C2=A0that the old client does not know about.



It's not clear that this restriction adds anything.=C2=A0 Module names =
are

required in resource URIs already, by "If a node in the path is

defined in another module than its parent node, [or its parent is the

datastore,] then module name followed by a colon character (":") =
is

prepended to the node name in the resource identifier."



3.5.3.1.=C2=A0 ABNF For Data Resource Identifiers



=C2=A0 =C2=A0 =C2=A0 =C2=A0api-path =3D "/"=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ("/&quo=
t; api-identifier

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0*(&q=
uot;/" (api-identifier | list-instance )))



I'm assuming there that <api-path> is the syntax for the path *wi=
thin*

the API's section of the URL space, that is, the string which is

appended to the entry point {+restconf}.=C2=A0 This seems necessary, as

otherwise the segments of the entry point path would have to conform

to <api-identifier>, and that restriction seems pointless.=C2=A0 But =
this

point should probably be clarified in the text.



It seems that this ABNF only applies to the paths of data resource

identifiers, not other resource types.=C2=A0 But in that case, why does the=


syntax allow "/" alone, which isn't the path of a data resour=
ce?

Indeed, a data resource path must start with "/data/" and be foll=
owed

by at least one segment.=C2=A0 ({+restconf}/data is the path of the

datastore resource, which is a different resource type.)



=C2=A0 =C2=A0 =C2=A0 =C2=A0key-value =3D string=C2=A0 =C2=A0 =C2=A0 ;; note=
 1



Of course, this is omitting the constraints about percent-encoding

reserved characters and comma.



=C2=A0 =C2=A0Note 1: The syntax for "api-identifier" and "ke=
y-value" MUST conform

=C2=A0 =C2=A0to the JSON identifier encoding rules in Section 4 of

=C2=A0 =C2=A0[I-D.ietf-netmod-yang-json].



Is this note actually correct?



3.6.=C2=A0 Operation Resource



=C2=A0 =C2=A0For example, if "module-A" defined a "reset&quo=
t; rpc operation, then

=C2=A0 =C2=A0invoking the operation from "module-A" would be requ=
ested as follows:



It seems like 'from "module-A"' is redundant in this cont=
ext; we've

already stated that the operation is in module-A.



=C2=A0 =C2=A0All operation resources representing RPC operations supported =
by the

=C2=A0 =C2=A0server MUST be identified in the {+restconf}/operations subtre=
e

=C2=A0 =C2=A0defined in Section 3.3.2.=C2=A0 Operation resources representi=
ng YANG

=C2=A0 =C2=A0actions are not identified in this subtree since they are invo=
ked

=C2=A0 =C2=A0using a URI within the {+restconf}/data subtree.



Isn't this paragraph redundant given the discussion at the beginning
of the section?



3.6.2.=C2=A0 Encoding Operation Resource Output Parameters



=C2=A0 =C2=A0The request URI is not returned in the response.=C2=A0 This UR=
I might have

=C2=A0 =C2=A0context information required to associate the output to the sp=
ecific

=C2=A0 =C2=A0"rpc" or "action" statement used in the re=
quest.



Doesn't HTTP always allow the client to associate the response with

the request that generated it?=C2=A0 If so, this paragraph is not really
correct, as a returned request URI will not be "required" for the=


client to perform the association.=C2=A0 Perhaps what is meant is

"knowledge of the request URI is needed to associate the output to the=


specific "rpc" or "action" statement referenced in the =
request".



3.8.=C2=A0 Event Stream Resource



=C2=A0 =C2=A0The available streams can be retrieved from the stream list, w=
hich

=C2=A0 =C2=A0specifies the syntax and semantics of a stream resource.



Shouldn't that be "... the syntax and semantics of the stream reso=
urces"?



3.9.=C2=A0 Errors YANG Data Template



=C2=A0 =C2=A0An "errors" YANG data template models a collection o=
f error

=C2=A0 =C2=A0information [...]



Presumably, 'The "errors" YANG data template ...'.



4.=C2=A0 Operations



=C2=A0 =C2=A0The following table shows how the RESTCONF operations relate t=
o

=C2=A0 =C2=A0NETCONF protocol operations and edit operations, which are ide=
ntified

=C2=A0 =C2=A0with the NETCONF "nc:operation" attribute.



For people who don't know NETCONF, it would be clearer to say

'... NETCONF protocol operations, and for the NETCONF edit operations,<=
br>
the "nc:operation" attribute.'



=C2=A0 =C2=A0In particular, RESTCONF is compatible with the NETCONF

=C2=A0 =C2=A0Access Control Model (NACM) [RFC6536], as there is a specific =
mapping

=C2=A0 =C2=A0between RESTCONF and NETCONF operations, defined in Section 4.=




Since this text is contains in Section 4, you could omit "defined in
Section 4".



=C2=A0 =C2=A0Implementation of all methods (except PATCH) are defined in
=C2=A0 =C2=A0[RFC7231].=C2=A0 This section defines the RESTCONF protocol us=
age for each

=C2=A0 =C2=A0HTTP method.



Why no RFC reference for the definition of PATCH?



4.2.=C2=A0 HEAD



=C2=A0 =C2=A0The HEAD method is sent by the client to retrieve just the hea=
ders

=C2=A0 =C2=A0that would be returned for the comparable GET method, without =
the

=C2=A0 =C2=A0response message-body.=C2=A0 It is supported for all resource =
types,

=C2=A0 =C2=A0except operation resources.



It seems a lot safer (and future-proof) to say "It is supported by all=


resources that support GET."



Also, it might be helpful to expand the first sentence, "... just the<=
br>
headers (which contain the metadata for a resource) ...".



4.3.=C2=A0 GET



=C2=A0 =C2=A0The request MUST contain a request URI that contains at least =
the

=C2=A0 =C2=A0entry point.



Uses of the term "entry point" are scattered through the document=
 but

not listed in 1.1.5.



I assume that it is implicit how a JSON GET should return multiple

values.=C2=A0 It might help the reader to include an example of a GET that<=
br>
returns multiple nodes (using JSON, of course).



BTW, what ETag and timestamp is returned by a GET whose URI identifies

more than one value?



4.5.=C2=A0 PUT



=C2=A0 =C2=A0If the target resource represents a YANG list instance, then t=
he PUT

=C2=A0 =C2=A0method MUST NOT change any key leaf values in the message-body=


=C2=A0 =C2=A0representation.



Shouldn't this be "... any key leaf values in the instance."?=




4.6.1.=C2=A0 Plain Patch



=C2=A0 =C2=A0Please see

=C2=A0 =C2=A0[I-D.ietf-netconf-yang-patch] for an alternate media-type supp=
orting

=C2=A0 =C2=A0the ability to delete child resources.=C2=A0 The YANG Patch Me=
dia Type

=C2=A0 =C2=A0allows multiple sub-operations (e.g., merge, delete) within a =
single

=C2=A0 =C2=A0PATCH operation.



It seems these two sentences would be clearer if they were combined:



=C2=A0 =C2=A0Please see [I-D.ietf-netconf-yang-patch] for an alternate

=C2=A0 =C2=A0media-type that supports the deleting child resources and

=C2=A0 =C2=A0specifying multiple sub-operations (e.g., merge, delete) withi=
n a

=C2=A0 =C2=A0single PATCH operation.



--



=C2=A0 =C2=A0If the target resource represents a YANG list instance, then t=
he

=C2=A0 =C2=A0PATCH method MUST NOT change any key leaf values in the messag=
e-body

=C2=A0 =C2=A0representation.



Shouldn't that be "... any key leaf values in the instance"?<=
br>


Section 4.6.1 needs to specify that the plain patch operation never

returns a response message-body.



4.7.=C2=A0 DELETE



=C2=A0 =C2=A0To delete a resource such as the "album" resource, t=
he client might

=C2=A0 =C2=A0send:



This would be clearer if it was



=C2=A0 =C2=A0To delete the "album" resource with the key "Wa=
sting Light", the client

=C2=A0 =C2=A0might send:



4.8.2.=C2=A0 The "depth" Query Parameter



=C2=A0 =C2=A0The "depth" parameter is used to specify the number =
of nest levels

=C2=A0 =C2=A0returned in a response for a GET method.



This would be better as 'Data nodes with a depth value exceeding the
"depth" parameter are not returned in a response for a GET method=
.'



=C2=A0 =C2=A0The first nest-level consists of the requested data node itsel=
f.



It seems that this would be more clear as "The requested data node

itself has depth value of 1."



=C2=A0 =C2=A0If the "fields" parameter (Section 4.8.3) is used to=
 select

=C2=A0 =C2=A0descendant data nodes, these nodes all have a depth value of 1=
.



You want to augment this as:



=C2=A0 =C2=A0If the "fields" parameter (Section 4.8.3) is used to=
 select

=C2=A0 =C2=A0descendant data nodes, these nodes and all their ancestors hav=
e a

=C2=A0 =C2=A0depth value of 1.



The following text could be clarified by adding parentheses around

this sentence:



=C2=A0 =C2=A0(This has the effect of including the nodes specified by the
=C2=A0 =C2=A0fields, even if the "depth" value is less than the a=
ctual depth

=C2=A0 =C2=A0level of the specified fields.)



--



=C2=A0 =C2=A0Any child nodes which are contained within a parent node have =
a

=C2=A0 =C2=A0depth value that is 1 greater than its parent.



Probably better as "Any other child node has a depth value that is ...=
".



=C2=A0 =C2=A0By default, the server will include all sub-resources within a=


=C2=A0 =C2=A0retrieved resource, which have the same resource type as the
=C2=A0 =C2=A0requested resource.=C2=A0 The exception is the datastore resou=
rce.=C2=A0 If

=C2=A0 =C2=A0this resource type is retrieved then by default the datastore =
and all

=C2=A0 =C2=A0child data resources are returned.



This specification requires that "resource type" be well-defined.=




4.8.3.=C2=A0 The "fields" Query Parameter



There should be a note that using "fields" does not select out a =
set

of nodes whose values are returned as a *set* of values, it returns a

*single* value, which is the value of the target data node, pruned by

the removal of all nodes that are not ancestors of or descendants of

one of the nodes specified in the "fields" parameter.=C2=A0 This =
is

particularly important when considering the interaction of "fields&quo=
t;

and "depth", and also is significant when the response representa=
tion

is XML.



4.8.4.=C2=A0 The "filter" Query Parameter



=C2=A0 =C2=A0This parameter is only allowed for GET methods on a text/event=
-stream

=C2=A0 =C2=A0data resource.



This is probably better put as "... on an event stream resource".=




Similarly in section 4.8.7.



4.8.7.=C2=A0 The "start-time" Query Parameter



=C2=A0 =C2=A0If this query parameter is supported by the server, then the &=
quot;replay"

=C2=A0 =C2=A0query parameter URI MUST be listed in the "capability&quo=
t; leaf-list in

=C2=A0 =C2=A0Section 9.3.=C2=A0 The "stop-time" query parameter M=
UST also be supported

=C2=A0 =C2=A0by the server.



For correctness, I think you need to join the two sentences:

'... leaf-list in Section 9.3, and the "stop-time" query para=
meter

MUST ...'.



Similarly in section 4.8.8.



4.8.9.=C2=A0 The "with-defaults" Query Parameter



=C2=A0 =C2=A0If the "with-defaults" parameter is set to "rep=
ort-all-tagged" then

=C2=A0 =C2=A0the server MUST adhere to the defaults reporting behavior defi=
ned in

=C2=A0 =C2=A0Section 3.4 of [RFC6243].



This needs a note that section 5.3 provides additional information

about how default values are marked in responses when "with-defaults&q=
uot;

is "report-all-tagged".



5.2.=C2=A0 Message Encoding



=C2=A0 =C2=A0JSON encoding rules are defined in

=C2=A0 =C2=A0[I-D.ietf-netmod-yang-json].=C2=A0 JSON encoding of metadata i=
s defined in

=C2=A0 =C2=A0[I-D.ietf-netmod-yang-metadata].



There needs to be some sort of juncture between these two sentences.

Does I-D.ietf-netmod-yang-json apply to metadata as well?=C2=A0 If so, the<=
br>
second sentence should start "Additional JSON encoding rules for

metadata are ...".=C2=A0 If not, the subject of the first sentence sho=
uld

be modified to show that metadata is excluded.=C2=A0 ("JSON encoding r=
ules

for data are ..."?)



=C2=A0 =C2=A0Response output content

=C2=A0 =C2=A0encoding format is identified with the Accept header in the re=
quest.



This should be



=C2=A0 =C2=A0The response output content encoding formats that the client w=
ill

=C2=A0 =C2=A0accept are identified with the Accept header in the request.


--



=C2=A0 =C2=A0File extensions encoded

=C2=A0 =C2=A0in the request are not used to identify format encoding.



I don't know of any place where a file extension can be encoded in the<=
br>
request.=C2=A0 But I get the unpleasant feeling that some server in the

wild has been seen with this behavior and this warning is needed!



5.3.=C2=A0 RESTCONF Metadata



=C2=A0 =C2=A0With the XML encoding, the metadata is encoded as attributes i=
n XML.



There should be some reference here as to how it should be done.

Presumably this is a reference to RFC 6243.



5.3.2.=C2=A0 JSON MetaData Encoding Example



=C2=A0 =C2=A0[...] so the YANG module name has to be assigned instead of de=
rived

=C2=A0 =C2=A0from the YANG module name.



I don't think this is can be correct; one use of "YANG module name=
" is

probably intended to be something else.



"MetaData" should be "Metadata".



6.3.1.=C2=A0 NETCONF Event Stream



=C2=A0 =C2=A0The server SHOULD support the "NETCONF" notification=
 stream defined

=C2=A0 =C2=A0in [RFC5277].



It might help to note that the reference is to section 3.2.3 of RFC

5277.



Is "notification stream" the same as "event stream"?=C2=
=A0 It seems like

the draft should use one term or the other consistently.



There is a lot of information about query parameters here, but it

seems that it duplicates the discussion of query parameters elsewhere

in the draft.=C2=A0 Could it be abbreviated?



6.4.=C2=A0 Receiving Event Notifications



=C2=A0 =C2=A0The structure of the event data is based on the "notifica=
tion"

=C2=A0 =C2=A0element definition in Section 4 of [RFC5277].=C2=A0 It MUST co=
nform to the

=C2=A0 =C2=A0schema for the "notification" element in Section 4 o=
f [RFC5277],

=C2=A0 =C2=A0except the XML namespace for this element is defined as:



=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:ietf-restconf



"this element" is somewhat ambiguous; probably better as "th=
e event

data element".



=C2=A0 =C2=A0RESTCONF servers that do send the

=C2=A0 =C2=A0"id" field MUST still support the "startTime&qu=
ot; query parameter as the

=C2=A0 =C2=A0preferred means for a client to specify where to restart the e=
vent

=C2=A0 =C2=A0stream.



It seems "startTime" should be "start-time".



But what is the significance of "MUST" here?=C2=A0 Implementing
"start-time" is always optional (section 6.3.1).=C2=A0 Perhaps it=
 would

work to say



=C2=A0 =C2=A0 RESTCONF servers that send the "id" field SHOULD su=
pport the

=C2=A0 =C2=A0 "start-time" query parameter, as "start-time&q=
uot; is the preferred

=C2=A0 =C2=A0 means for specifying where to restart fetching the event stre=
am.



7.=C2=A0 Error Reporting



=C2=A0 =C2=A0The <rpc-error> element returned in NETCONF error

=C2=A0 =C2=A0responses contains some useful information.



I got confused by this sentence.=C2=A0 IIRC, this section is about error
responses generally, not just error responses for RPC operations.=C2=A0 It<=
br>
seems the problem is that *all* Netconf operations are considered

RPCs, so <rpc-error> covers all Netconf errors.=C2=A0 I think this co=
uld be

made less confusing by combining this sentence with the following one

as:



=C2=A0 =C2=A0The error information that NETCONF error responses contain in =
the

=C2=A0 =C2=A0<rpc-error> element is adapted for use in RESTCONF, and =
an <errors>

=C2=A0 =C2=A0data tree information is returned for "4xx" and &quo=
t;5xx" class of

=C2=A0 =C2=A0status codes.



--



=C2=A0 =C2=A0[...] a mapping between the NETCONF <error-tag> value an=
d the HTTP status

=C2=A0 =C2=A0code is needed.



Better to say "a mapping from the ... to the HTTP status code is

needed." since the reverse mapping is not unique.



=C2=A0 =C2=A0The semantics and syntax for RESTCONF error messages are defin=
ed with

=C2=A0 =C2=A0the "yang-errors" YANG data template extension, foun=
d in Section 8.



What is a "YANG data template extension"?=C2=A0 It probably means=
 "YANG

data template extension statement", but I think it could be reduced to=


'the "errors" YANG data template'.=C2=A0 (Of course, see =
my comments about

"YANG data template" at the beginning.)



7.1.=C2=A0 Error Response Message



=C2=A0 =C2=A0The Content-Type of this response

=C2=A0 =C2=A0message MUST be a subtype of application/yang-data (see exampl=
e

=C2=A0 =C2=A0below).



This isn't the meaning of "subtype", which seems to be restri=
cted (RFC

6838) to mean the part of the media type after "/".=C2=A0 This sh=
ould work,

though:



=C2=A0 =C2=A0The Content-Type of this response message MUST be

=C2=A0 =C2=A0application/yang-data, plus optionally a structured syntax nam=
e

=C2=A0 =C2=A0suffix.



"structured syntax name suffix" is defined in RFC 6838 section 4.=
2.8.



=C2=A0 =C2=A0The client SHOULD specify the desired encoding for error messa=
ges by

=C2=A0 =C2=A0specifying the appropriate media-type in the Accept header.=C2=
=A0 If no

=C2=A0 =C2=A0error media is specified, [...]



The client will specify the desired encoding for all responses, which

perforce applies to error messages as well.=C2=A0 This can probably be

reduced to:



=C2=A0 =C2=A0The client SHOULD specify the desired encoding(s) for response=


=C2=A0 =C2=A0messages by specifying the appropriate media-type(s) in the Ac=
cept

=C2=A0 =C2=A0header.=C2=A0 If the client did not specify an Accept header, =
[...]



--



=C2=A0 =C2=A0No response message-body content is expected by the

=C2=A0 =C2=A0client in this example.



Well, no content is expected on success, but the client was prepared

for failure by providing an Accept.=C2=A0 Better say



=C2=A0 =C2=A0There would be no response message-body content if this operat=
ion

=C2=A0 =C2=A0was successful.



The indentation of the DELETE example request and its response are

different, which should probably be fixed.



8.=C2=A0 RESTCONF module



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that the YANG definitions within this modu=
le do not

=C2=A0 =C2=A0 =C2=A0 =C2=A0 represent configuration data of any kind.



Are there kinds of configuration data?=C2=A0 Seems like it would be better<=
br>
to say "... are never configuration data."



And indeed, we could add 'config "false";' to the top-lev=
el objects to

specify that directly in Yang.



=C2=A0 =C2=A0 =C2=A0...



=C2=A0 =C2=A0 =C2=A0extension yang-data {

=C2=A0 =C2=A0 =C2=A0 argument name {



Is there a reason that the substatements of this extension statement

are indented only 1 space?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 yin-element true;

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This extension is used to specify a YANG =
data template which

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0represents conceptual data defined in YAN=
G. It is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intended to describe hierarchical data in=
dependent of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol context or specific message enco=
ding format.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Data definition statements within this ex=
tension specify

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the generic syntax for the specific YANG =
data template.



"this extension" is ambiguous, since it seems to me that it might=
 be

referring to the immediately preceding extension-statement.=C2=A0 I think
the last sentence would be clearer as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Data definition statements within a yang-=
data extension

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statement specify the generic syntax for =
the specific YANG

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data template, whose name is the argument=
 of the yang-data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extension statement.



--



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This extension is ignored unless it appea=
rs as a top-level

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statement. It SHOULD contain data definit=
ion statements

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that result in exactly one container data=
 node definition.



It seems like you can assure that the extension will never be used in

an improper place, since only this document will use it.=C2=A0 Perhaps



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The yang-data extension MUST only be a to=
p-level statement of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a module.=C2=A0 It MUST contain only one =
schema node, which is a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0container.



--



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This allows compliant translation to an X=
ML instance

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0document for each YANG data template.



This needs to specify the source of the name of the top-level XML

element:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Instances of a YANG data template can thu=
s be translated into

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0XML instances, whose top-level element co=
rresponds to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0top-level container.



--



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The following data-def-stmt sub-statement=
s have special

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0meaning when used within a yang-data-reso=
urce extension

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statement.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- The list-stmt is not required to have a=
 key-stmt defined.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- The if-feature-stmt is ignored if prese=
nt.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- The config-stmt is ignored if present.<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- The available identity values for any &=
#39;identityref'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf or leaf-list nodes is limited=
 to the module

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing this extension statemen=
t, and the modules

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0imported into that module.



It seems like poor practice to have the extension be described as

changing the semantics of Yang.=C2=A0 Better would be to turn these into
constraints, so that the valid contents of yang-data are a subset of

Yang, but that subset has the same semantics as Yang prescribes:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- The if-feature-stmt must not be present=
.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- If the config-stmt is present, its valu=
e must be 'false'.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- The available identity values for any &=
#39;identityref'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf or leaf-list nodes is limited=
 to the module

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing this extension statemen=
t, and the modules

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0imported into that module. [unchan=
ged!]



The item "The list-stmt is not required to have a key-stmt defined.&qu=
ot;

is redundant, since everything inside yang-data is not configuration

data, and non-configuration lists need not have keys.



This section contains the following lines which name media types which

do not exist.=C2=A0 Presumably this is a simple oversight and the correct
types are known.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-api resource type."=
;;



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application/yang-api resource typ=
e.";



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Container representin=
g the application/yang-datastore



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (application/yang-operatio=
n),



9.=C2=A0 RESTCONF Monitoring



=C2=A0 =C2=A0The "ietf-restconf-monitoring" module provides infor=
mation about the

=C2=A0 =C2=A0RESTCONF protocol capabilities and event notification streams<=
br>
=C2=A0 =C2=A0available from the server.=C2=A0 A RESTCONF server MUST implem=
ent the "/

=C2=A0 =C2=A0restconf-state/capabilities" container in this module.


Note that there is a line break in an incorrect place at the end of

the third line.=C2=A0 Presumably it is due to an extraneous space in the
XML2RFC file.



It seems like the second sentence would be more informative as "A

RESTCONF server MUST implement the ietf-restconf-monitoring module."
Since restconf-state/capabilities is mandatory within the module, its

existence need not be stated here.



=C2=A0 =C2=A0YANG Tree Diagram for "ietf-restconf-monitoring" mod=
ule:



Shouldn't that be "YANG tree diagram ..."?



The nodes 'description' and 'replay-support' are shown as o=
ptional in

the tree diagram:



=C2=A0 =C2=A0+--ro restconf-state

=C2=A0 =C2=A0 =C2=A0 +--ro streams

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro stream* [name]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro description?=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro replay-support?=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0boolean

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro replay-log-creation-time?=
=C2=A0 =C2=A0yang:date-and-time



but there is no 'mandatory "false";' for those leafs in t=
he module

definition in section 9.3:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf description {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "Descripti=
on of stream content";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reference

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"RFC 5277, Sect=
ion 3.4, <description> element.";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf replay-support {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates if r=
eplay buffer supported for this stream.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If 'true', =
then the server MUST support the 'start-time'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and 'stop-time&=
#39; query parameters for this stream.";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reference

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"RFC 5277, Sect=
ion 3.4, <replaySupport> element.";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}



And the description should say that if replay-support is missing, its

assumed value is false[?].=C2=A0 Or should a 'default' statement be=


employed?



9.1.2.=C2=A0 The "defaults" Protocol Capability URI



This section is awkwardly phrased.=C2=A0 Perhaps:



=C2=A0 =C2=A0This URI identifies the "basic-mode" defaults handli=
ng mode that is

=C2=A0 =C2=A0used by the server for processing default leafs in requests fo=
r

=C2=A0 =C2=A0data resources.=C2=A0 This protocol capability URI MUST be sup=
ported by

=C2=A0 =C2=A0the server, and MUST be listed in the "capability" l=
eaf-list in

=C2=A0 =C2=A0Section 9.3.



=C2=A0 =C2=A0 =C2=A0 +----------+------------------------------------------=
--------+

=C2=A0 =C2=A0 =C2=A0 | Name=C2=A0 =C2=A0 =C2=A0| URI=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 +----------+------------------------------------------=
--------+

=C2=A0 =C2=A0 =C2=A0 | defaults | urn:ietf:params:restconf:capability:defau=
lts:1.0 |

=C2=A0 =C2=A0 =C2=A0 +----------+------------------------------------------=
--------+



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0RESTCONF defaults capability URI



=C2=A0 =C2=A0This URI MUST have attached a query a parameter named "ba=
sic-mode"

=C2=A0 =C2=A0with one of the values listed below:



=C2=A0 =C2=A0+------------------+------------------------------------------=
------+

=C2=A0 =C2=A0| Value=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Description=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0+------------------+------------------------------------------=
------+

=C2=A0 =C2=A0| report-all=C2=A0 =C2=A0 =C2=A0 =C2=A0| No data nodes are con=
sidered default=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0| trim=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Values=
 set to the YANG default-stmt value are=C2=A0 |

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | default=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |

=C2=A0 =C2=A0| explicit=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Values set by th=
e client are never considered=C2=A0 |

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | default=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |

=C2=A0 =C2=A0+------------------+------------------------------------------=
------+



=C2=A0 =C2=A0The "basic-mode" behavior of the server is as specif=
ied for this

=C2=A0 =C2=A0value in "With-Defaults Capability for NETCONF" [RFC=
6243]:



=C2=A0 =C2=A0If the "basic-mode" is set to "report-all"=
 then the server MUST

=C2=A0 =C2=A0adhere to the defaults handling behavior defined in Section 2.=
1 of

=C2=A0 =C2=A0[RFC6243].

=C2=A0 =C2=A0[...]



9.2.=C2=A0 restconf-state/streams



=C2=A0 =C2=A0This optional container provides access to the event notificat=
ion

=C2=A0 =C2=A0streams supported by the server.=C2=A0 The server MAY omit thi=
s container

=C2=A0 =C2=A0if no event notification streams are supported.



The second sentence is redundant, given that "streams" is a

non-presence container, but it seems reasonable to warn the

implementer here.



10.1.=C2=A0 modules-state



=C2=A0 =C2=A0This mandatory container holds the identifiers for the YANG da=
ta

=C2=A0 =C2=A0model modules supported by the server.



This isn't how I'd phrase it.=C2=A0 I would say that modules-state/=
module

holds the identifiers.=C2=A0 Perhaps omit this section and number 10.1.1 as=


"10.1"?



10.1.1.=C2=A0 modules-state/module



If I understand correctly, the resource tree under {+restconf} is

described by the ietf-restconf module.=C2=A0 All data resources not defined=


by ietf-restconf are descendants of {+restconf}/data, including the

mandatory ietf-restconf-monitoring module.=C2=A0 But is ietf-restconf

listed in

{+restconf}/data/ietf-restconf-monitoring:modules-state/module?=C2=A0 I can=


see that this could be argued either way.



12.=C2=A0 Security Considerations



=C2=A0 =C2=A0The "ietf-restconf-monitoring" YANG module defined i=
n this memo is

=C2=A0 =C2=A0designed to be accessed via the NETCONF protocol [RFC6241].=C2=
=A0 The

=C2=A0 =C2=A0lowest NETCONF layer is the secure transport layer, and the
=C2=A0 =C2=A0mandatory-to-implement secure transport is Secure Shell (SSH)<=
br>
=C2=A0 =C2=A0[RFC6242].=C2=A0 The NETCONF access control model [RFC6536] pr=
ovides the

=C2=A0 =C2=A0means to restrict access for particular NETCONF users to a pre=
-

=C2=A0 =C2=A0configured subset of all available NETCONF protocol operations=
 and

=C2=A0 =C2=A0content.



This reads oddly.=C2=A0 "ietf-restconf-monitoring" is designed to=
 be

accessed via the RESTCONF protocol.=C2=A0 However, RESTCONF does use the
NETCONF access control model.=C2=A0 OTOH, this paragraph really isn't a=
bout

ietf-restconf-monitoring, it's very general.=C2=A0 It seems to me that =
you

want (and I may have the details wrong):



=C2=A0 =C2=A0The lowest RESTCONF layer is HTTPS, and the mandatory-to-imple=
ment

=C2=A0 =C2=A0secure transport is TLS [RFC5246].=C2=A0 The RESTCONF protocol=
 uses the

=C2=A0 =C2=A0NETCONF access control model [RFC6536], which provides the mea=
ns to

=C2=A0 =C2=A0restrict access for particular RESTCONF users to a preconfigur=
ed

=C2=A0 =C2=A0subset of all available RESTCONF protocol operations and conte=
nt.



=C2=A0 =C2=A0This section provides security considerations for the resource=
s

=C2=A0 =C2=A0defined by the RESTCONF protocol.=C2=A0 Security consideration=
s for

=C2=A0 =C2=A0HTTPS are defined in [RFC7230].=C2=A0 RESTCONF does not specif=
y which

=C2=A0 =C2=A0YANG modules a server needs to support, other than the

=C2=A0 =C2=A0"ietf-restconf-monitoring" module.=C2=A0 Security co=
nsiderations for the

=C2=A0 =C2=A0other modules manipulated by RESTCONF can be found in the docu=
ments

=C2=A0 =C2=A0defining those YANG modules.



14.1.=C2=A0 Normative References



This draft has the longest normative references list I've ever seen!


14.2.=C2=A0 Informative References



=C2=A0 =C2=A0[rest-dissertation]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fielding, R., "Archit=
ectural Styles and the Design of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network-based Software Arc=
hitectures", 2000.



Surely there is additional bibliographic information available for

this!



Appendix C.=C2=A0 Example YANG Module



=C2=A0 =C2=A0+---x play

=C2=A0 =C2=A0 =C2=A0 +--ro input

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro playlist=C2=A0 =C2=A0 =C2=A0 =C2=A0=
string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro song-number=C2=A0 =C2=A0 uint32



The "x" indicator is not listed in section 1.1.7.=C2=A0 Is it &qu=
ot;standard"

for Yang tree diagrams?



The "+---x" before "play" should be "+--x".=
=C2=A0 This will also fix the

indenting problem.



C.1.=C2=A0 example-jukebox YANG Module



=C2=A0 =C2=A0 =C2=A0 ...

=C2=A0 =C2=A0 =C2=A0 contact "support at example.com";



Comparing with the examples of the contact statement in

draft-ietf-netmod-rfc6020bis-14, it seems that this should be

"support@example.com".=




Appendix D.=C2=A0 RESTCONF Message Examples



=C2=A0 =C2=A0The examples within this document use the normative YANG modul=
e

=C2=A0 =C2=A0defined in Section 8 and the non-normative example YANG module=


=C2=A0 =C2=A0defined in Appendix C.1.



This would flow better (for me) if it included the module names:



=C2=A0 =C2=A0The examples within this document use the normative YANG modul=
e

=C2=A0 =C2=A0"ietf-restconf" defined in Section 8 and the non-nor=
mative example

=C2=A0 =C2=A0YANG module "example-jukebox" defined in Appendix C.=
1.



D.1.1.=C2=A0 Retrieve the Top-level API Resource



=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0 =C2=A0 Date: Mon, 23 Apr 2012 17:01:00 GMT

=C2=A0 =C2=A0 =C2=A0 Server: example-server

=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang-data+json



=C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-restconf:restconf": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "data" : {},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "operations" : {},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "yang-library-version" : "=
;2016-04-09"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 }



=C2=A0 =C2=A0The server will return the same response either way, which mig=
ht be

=C2=A0 =C2=A0as follows :



It's not really the "same response".=C2=A0 "conceptual d=
ata" seems better.



D.2.2.=C2=A0 Detect Resource Entity Tag Change



=C2=A0 =C2=A0In this example, the server just supports the datastore last-c=
hanged

=C2=A0 =C2=A0timestamp.=C2=A0 The client has previously retrieved the "=
;Last-Modified"

=C2=A0 =C2=A0header and has some value cached to provide in the following r=
equest

=C2=A0 =C2=A0to patch an "album" list entry with key value "=
Wasting Light".=C2=A0 Only

=C2=A0 =C2=A0the "genre" field is being updated.



IIRC, the "value cached" is the URI

/restconf/data/example-jukebox:jukebox/library/artist=3DFoo%20Fighters/albu=
m=3DWasting%20Light

for the album.=C2=A0 It seems this could be clearer as



=C2=A0 =C2=A0After the previous request, the client has cached the

=C2=A0 =C2=A0"Last-Modified" header and the Location header from =
the response to

=C2=A0 =C2=A0provide the following request to patch the "album" l=
ist entry with

=C2=A0 =C2=A0key value "Wasting Light".



And then change the If-Unmodified-Since header in the request to use

the value from the previous response, "Mon, 23 Apr 2012 17:03:00 GMT&q=
uot;.



D.2.3.=C2=A0 Edit a Datastore Resource



=C2=A0 =C2=A0In this example, the client modifies two different data nodes =
by

=C2=A0 =C2=A0sending a PATCH to the datastore resource:



"different" might be redundant.



It might be worth pointing out which nodes are being modified.=C2=A0 As far=


as I can see, the only modifiable nodes in the request data tree are

the "year" nodes, but the "year" for "Wasting Ligh=
t" in this update is

the same as in its creation in D.2.1.=C2=A0 Should the request be modified?=




D.2.4.=C2=A0 Edit a Data Resource



=C2=A0 =C2=A0In this example, the client modifies one data nodes by sending=
 a

=C2=A0 =C2=A0PATCH to the data resource (URI wrapped for display purposes o=
nly):



=C2=A0 =C2=A0PATCH /restconf/data/example-jukebox:jukebox/library/

=C2=A0 =C2=A0 =C2=A0 artist=3DNick%20Cave%20and%20the%Bad%20Seeds HTTP/1.1<=
br>
=C2=A0 =C2=A0Host: example.com

=C2=A0 =C2=A0Content-Type: application/yang-data



=C2=A0 =C2=A0<artist xmlns=3D"http://example.com/ns/exa=
mple-jukebox">

=C2=A0 =C2=A0 =C2=A0<name>Nick Cave and the Bad Seeds</name>
=C2=A0 =C2=A0 =C2=A0<album>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>The Good Son</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<year>1990</year>

=C2=A0 =C2=A0 =C2=A0</album>

=C2=A0 =C2=A0</artist>



Should be "one data node".



The example isn't very clear to me:=C2=A0 Which data node(s) is the PAT=
CH

intended to modify?=C2=A0 Does "modify a data node" mean that one=
 single

leaf is being modified, or does it include modification of an entire

subtree?=C2=A0 "the data resource" seems to be an "artist&qu=
ot; node, but that

node per se isn't being modified.



I think it would help to write what changes the PATCH was intended to

cause, and adjust the wording accordingly.



D.3.2.=C2=A0 "depth" Parameter



=C2=A0 =C2=A0To determine if 1 or more resource instances exist for a given=
 target

=C2=A0 =C2=A0resource, the value "1" is used.



Usually, this "1" would be spelled out as "one".



The following two sections probably should have short text identifying

what they illustrate.=C2=A0 E.g.,



D.3.7.=C2=A0 "start-time" Parameter



=C2=A0 =C2=A0The following URI shows an example of a start-time specificati=
on:



=C2=A0 =C2=A0// start-time =3D 2014-10-25T10:02:00Z

=C2=A0 =C2=A0GET /streams/NETCONF?start-time=3D2014-10-25T10%3A02%3A00Z



D.3.8.=C2=A0 "stop-time" Parameter



=C2=A0 =C2=A0The following URI shows an example of a stop-time specificatio=
n:



=C2=A0 =C2=A0// stop-time =3D 2014-10-25T12:31:00Z

=C2=A0 =C2=A0GET /mystreams/NETCONF?stop-time=3D2014-10-25T12%3A31%3A00Z


This example is invalid, since it doesn't contain a start-time.

(section 4.8.8) Perhaps:



=C2=A0 =C2=A0The following URI shows an example of a stop-time specificatio=
n

=C2=A0 =C2=A0(lines wrapped for display purposes only):



=C2=A0 =C2=A0// start-time =3D 2014-10-25T10:02:00Z

=C2=A0 =C2=A0// stop-time =3D 2014-10-25T12:31:00Z

=C2=A0 =C2=A0GET /streams/NETCONF?

=C2=A0 =C2=A0 =C2=A0 start-time=3D2014-10-25T10%3A02%3A00Z&

=C2=A0 =C2=A0 =C2=A0 stop-time=3D2014-10-25T12%3A31%3A00Z



D.3.9.=C2=A0 "with-defaults" Parameter



=C2=A0 =C2=A0The following YANG module is assumed for this example.



=C2=A0 =C2=A0 =C2=A0module example-interface {

=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix "exif";

=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:example.com:params:xml:ns:ya=
ng:example-interface";



=C2=A0 =C2=A0 =C2=A0 =C2=A0container interfaces {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list interface {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key name;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name { type string; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf mtu { type uint32; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf status {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum up;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum down;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum testing;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0}



As far as I can tell, module "example-interface" isn't used i=
n this

section.=C2=A0 "example-interface" seems to be an abbreviated ver=
sion of

module "example" in section A.1 of RFC 6243, but with the semanti=
c

difference that "example-interface" omits the default statement t=
hat

drives the examples in this section.=C2=A0 It seems that you want to drop
"example-interface" entirely and start the section with:



=C2=A0 =C2=A0Assume the server implements the module "example" de=
fined in

=C2=A0 =C2=A0Appendix A.1 of [RFC6243].=C2=A0 Assume the server's datas=
tore is as

=C2=A0 =C2=A0defined in Appendix A.2 of [RFC6243].



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

Indentation of HTTP examples



1.5.=C2=A0 RESTCONF Extensibility

=C2=A0 =C2=A0 =C2=A0 GET /.well-known/host-meta HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

3.1.=C2=A0 Root Resource Discovery

=C2=A0 =C2=A0 =C2=A0 GET /.well-known/host-meta HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0 =C2=A0 GET /.well-known/host-meta HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0 =C2=A0 GET /top/restconf/operations=C2=A0 HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

3.3.1.=C2=A0 {+restconf}/data

=C2=A0 =C2=A0GET /restconf/data/example-jukebox:jukebox/library

=C2=A0 =C2=A0HTTP/1.1 200 OK

3.3.3.=C2=A0 {+restconf}/yang-library-version

=C2=A0 =C2=A0GET /restconf/yang-library-version=C2=A0 HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 200 OK

3.6.=C2=A0 Operation Resource

=C2=A0 =C2=A0POST /restconf/operations/module-A:reset HTTP/1.1

=C2=A0 =C2=A0POST /restconf/data/module-A:interfaces/reset-all HTTP/1.1

3.6.1.=C2=A0 Encoding Operation Resource Input Parameters

=C2=A0 =C2=A0POST /restconf/operations/example-ops:reboot HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 204 No Content

=C2=A0 =C2=A0 =C2=A0 POST /restconf/operations/example-ops:reboot HTTP/1.1<=
br>
=C2=A0 =C2=A0POST /restconf/data/example-actions:interfaces/interface=3Deth=
0

=C2=A0 =C2=A0HTTP/1.1 204 No Content

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-actions:interfaces/interfa=
ce=3Deth0

3.6.2.=C2=A0 Encoding Operation Resource Output Parameters

=C2=A0 =C2=A0POST /restconf/operations/example-ops:get-reboot-info HTTP/1.1=


=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0HTTP/1.1 200 OK

=C2=A0 =C2=A0POST /restconf/data/example-actions:interfaces/interface=3Deth=
0

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

3.6.3.=C2=A0 Encoding Operation Resource Errors

=C2=A0 =C2=A0POST /restconf/operations/example-ops:reboot HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 400 Bad Request

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 400 Bad Request

3.7.=C2=A0 Schema Resource

=C2=A0 =C2=A0GET /restconf/data/ietf-yang-library:modules-state/module=3D
=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

4.3.=C2=A0 GET

=C2=A0 =C2=A0GET /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 200 OK

4.4.1.=C2=A0 Create Resource Mode

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 201 Created

4.4.2.=C2=A0 Invoke Operation Mode

=C2=A0 =C2=A0 =C2=A0 POST /restconf/operations/example-jukebox:play=C2=A0 =
=C2=A0HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 204 No Content

4.5.=C2=A0 PUT

=C2=A0 =C2=A0 =C2=A0 PUT /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 204 No Content

=C2=A0 =C2=A0PUT /restconf/data/example-jukebox:jukebox/

4.6.1.=C2=A0 Plain Patch

=C2=A0 =C2=A0PATCH /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 204 No Content

4.7.=C2=A0 DELETE

=C2=A0 =C2=A0DELETE /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 204 No Content

5.3.1.=C2=A0 XML MetaData Encoding Example

=C2=A0 =C2=A0GET /restconf/data/interfaces/interface=3Deth1

=C2=A0 =C2=A0HTTP/1.1 200 OK

5.3.2.=C2=A0 JSON MetaData Encoding Example

=C2=A0 =C2=A0GET /restconf/data/interfaces/interface=3Deth1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

6.2.=C2=A0 Event Streams

=C2=A0 =C2=A0GET /restconf/data/ietf-restconf-monitoring:restconf-state/
=C2=A0 =C2=A0HTTP/1.1 200 OK

6.3.=C2=A0 Subscribing to Receive Notifications

=C2=A0 =C2=A0GET /restconf/data/ietf-restconf-monitoring:restconf-state/
=C2=A0 =C2=A0HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /streams/NETCONF HTTP/1.1

=C2=A0 =C2=A0GET /streams/NETCONF HTTP/1.1

7.1.=C2=A0 Error Response Message

=C2=A0 =C2=A0DELETE /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 409 Conflict

=C2=A0 =C2=A0POST /restconf/data/example-jukebox:jukebox HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 409 Conflict

8.=C2=A0 RESTCONF module

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0POST /restcon=
f/operations/ietf-system:system-restart

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GET /restconf=
/operations

D.1.1.=C2=A0 Retrieve the Top-level API Resource

=C2=A0 =C2=A0GET /.well-known/host-meta HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf=C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 200 OK

D.1.2.=C2=A0 Retrieve The Server Module Information

=C2=A0 =C2=A0GET /restconf/data/ietf-yang-library:modules-state HTTP/1.1
=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

D.1.3.=C2=A0 Retrieve The Server Capability Information

=C2=A0 =C2=A0GET /restconf/data/ietf-restconf-monitoring:restconf-state/
=C2=A0 =C2=A0HTTP/1.1 200 OK

D.2.1.=C2=A0 Create New Data Resources

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebox/library HT=
TP/1.1

=C2=A0 =C2=A0HTTP/1.1 201 Created

=C2=A0 =C2=A0POST /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 201 Created

D.2.2.=C2=A0 Detect Resource Entity Tag Change

=C2=A0 =C2=A0 =C2=A0 PATCH /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP/1.1

=C2=A0 =C2=A0HTTP/1.1 412 Precondition Failed

D.2.3.=C2=A0 Edit a Datastore Resource

=C2=A0 =C2=A0PATCH /restconf/data HTTP/1.1

D.2.4.=C2=A0 Edit a Data Resource

=C2=A0 =C2=A0PATCH /restconf/data/example-jukebox:jukebox/library/

D.3.1.=C2=A0 "content" Parameter

=C2=A0 =C2=A0GET /restconf/data/example-events:events?content=3Dall

=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf/data/example-events:events?content=3Dconfig

=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf/data/example-events:events?content=3Dnonconfig
=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

D.3.2.=C2=A0 "depth" Parameter

=C2=A0 =C2=A0GET /restconf/data/example-jukebox:jukebox?depth=3Dunbounded
=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/1.1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf/data/example-jukebox:jukebox?depth=3D1 HTTP/1.1<=
br>
=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf/data/example-jukebox:jukebox?depth=3D3 HTTP/1.1<=
br>
=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

D.3.3.=C2=A0 "fields" Parameter

=C2=A0 =C2=A0GET /restconf/data?fields=3Dietf-yang-library:modules-state/
=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

D.3.4.=C2=A0 "insert" Parameter

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 201 Created

D.3.5.=C2=A0 "point" Parameter

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebox/

=C2=A0 =C2=A0HTTP/1.1 204 No Content

D.3.6.=C2=A0 "filter" Parameter

=C2=A0 =C2=A0 =C2=A0 GET /streams/NETCONF?filter=3D%2Fevent%2Fevent-class%3=
D'fault'

=C2=A0 =C2=A0 =C2=A0 GET /streams/NETCONF?filter=3D%2Fevent%2Fseverity%3C%3=
D4

=C2=A0 =C2=A0 =C2=A0 GET /streams/SNMP?filter=3D%2FlinkUp%7C%2FlinkDown

=C2=A0 =C2=A0 =C2=A0 GET /streams/NETCONF?

=C2=A0 =C2=A0 =C2=A0 GET /streams/critical-syslog?

=C2=A0 =C2=A0 =C2=A0 GET /streams/NETCONF?

=C2=A0 =C2=A0 =C2=A0 GET /streams/NETCONF?filter=3D(%2Fm1%3A*%20or%20%2Fm2%=
3A*)

D.3.7.=C2=A0 "start-time" Parameter

=C2=A0 =C2=A0GET /streams/NETCONF?start-time=3D2014-10-25T10%3A02%3A00Z

D.3.8.=C2=A0 "stop-time" Parameter

=C2=A0 =C2=A0GET /mystreams/NETCONF?stop-time=3D2014-10-25T12%3A31%3A00Z
D.3.9.=C2=A0 "with-defaults" Parameter

=C2=A0 =C2=A0GET /restconf/data/example:interfaces/interface=3Deth1 HTTP/1.=
1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

=C2=A0 =C2=A0GET /restconf/data/example:interfaces/interface=3Deth1

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK

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



Dale



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a113ab81a5dd5d90538fa4c56--